[
Lists Home |
Date Index |
Thread Index
]
Simon St.Laurent wrote:
> robin.berjon@expway.fr (Robin Berjon) writes:
>>In fact, if HTTP 1.1 content codings took parametres, we'd have the
>>answer already. Damn :)
>
> I'm not entirely sure what you're looking for - and Len's reply makes me
> even less certain - but Content-Type header fields definitely take
> parameters:
Content-Type, yes, Content-Encoding/Accept-Encoding (aka content codings), no:
http://www.w3.org/Protocols/rfc2068/rfc2068
Section 3.5
content-coding = token
All content-coding values are case-insensitive. HTTP/1.1 uses
content-coding values in the Accept-Encoding (section 14.3) and
Content-Encoding (section 14.12) header fields. Although the value
describes the content-coding, what is more important is that it
indicates what decoding mechanism will be required to remove the
encoding.
Section 14.3
The Accept-Encoding request-header field is similar to Accept, but
restricts the content-coding values (section 14.12) which are
acceptable in the response.
Accept-Encoding = "Accept-Encoding" ":"
#( content-coding )
An example of its use is
Accept-Encoding: compress, gzip
Section 14.12
The Content-Encoding entity-header field is used as a modifier to the
media-type. When present, its value indicates what additional content
codings have been applied to the entity-body, and thus what decoding
mechanisms MUST be applied in order to obtain the media-type
referenced by the Content-Type header field. Content-Encoding is
primarily used to allow a document to be compressed without losing
the identity of its underlying media type.
Content-Encoding = "Content-Encoding" ":" 1#content-coding
Content codings are defined in section 3.5. An example of its use is
Content-Encoding: gzip
--
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway http://expway.fr/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
