Query regarding Request Headers in HTTP/1.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Query regarding Request Headers in HTTP/1.1

priyanshu jain




Hi,

I have one query regarding Accept Headers in HTTP Request. From our program, client is sending below headers in request...

Type 1:

Accept-Encoding : Gzip
Accept-Encoding : deflate

Normally accept headers is like that

Type : 2
Accept-Encoding : Gzip, drflate.

My questions are :

1. Whether above request headers format (Type 1)is acceptable (or correct).
2. If yes, then how the server will deal with it.
3. In RFC2616, where its defined that we can have multiple accept headers with same "filed-value", like we stated above (Type 1).

regards
priyanshu


     


Reply | Threaded
Open this post in threaded view
|

Re: Query regarding Request Headers in HTTP/1.1

Julian Reschke

priyanshu jain wrote:

>
>
>
> Hi,
>
> I have one query regarding Accept Headers in HTTP Request. From our program, client is sending below headers in request...
>
> Type 1:
>
> Accept-Encoding : Gzip
> Accept-Encoding : deflate
>
> Normally accept headers is like that
>
> Type : 2
> Accept-Encoding : Gzip, drflate.
>
> My questions are :
>
> 1. Whether above request headers format (Type 1)is acceptable (or correct).

It is correct.

> 2. If yes, then how the server will deal with it.

The same way as with type 2.

> 3. In RFC2616, where its defined that we can have multiple accept headers with same "filed-value", like we stated above (Type 1).

"Multiple message-header fields with the same field-name MAY be present
in a message if and only if the entire field-value for that header field
is defined as a comma-separated list [i.e., #(values)]. It MUST be
possible to combine the multiple header fields into one "field-name:
field-value" pair, without changing the semantics of the message, by
appending each subsequent field-value to the first, each separated by a
comma. The order in which header fields with the same field-name are
received is therefore significant to the interpretation of the combined
field value, and thus a proxy MUST NOT change the order of these field
values when a message is forwarded." --
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.4.2.p.5>.

BR, Julian