On Sunday 18 August 2002 11:02 am, [EMAIL PROTECTED] wrote:
> My understanding - the HTTP spec doesn't ( and can't ) define a complete
> list of headers supporting multiple values. That's impossible given that
> additional headers are supported.
>
The spec does exactly that. It enumerates the processing for the headers it
defines. In section 5.3, "Unrecognized header fields are treated as
entity-header fields." [section 5.3]
In section 7.1, Entity Header Fields
The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and MUST be forwarded by
transparent proxies.
extension-header field-value is not defined as being a comma separated list,
so it shouldn't be treated as such.
The on point case would be a webdav server running inside a servlet container.
The webdav protocol actually does define a header that contains a list of
values, the DAV header. So should the webdav servlet expect the
extension-header to be parsed for it? It might be nice, but I can't see that
it's required.
> If the servlet spec requires getHeader() to return the 'concatenated value
> for multi-headers' - then the spec can't be implemented.
> If it requires getHeaders() to split headers that are multi-value and
> were sent concatenated - it can't be implemented ( and it's an API bug )
> It can be done only for the list of headers defined in the spec.
>
Can't be implemented is a little strong. After all, Tomcat used to pass this
test. The old connector used to parse out the Accept-Languages header, so as
to get the correct locale. I'd bet anything that the fact that this was
visible via getHeaders() is why the test is written the way it is. Tomcat was
actually used as a reference.
But, API bug is what I was arguing for originally. With getHeader and
getHeaders as speced, an application has no way of getting at the headers as
sent. The key is the 'list of headers defined in the spec'. The HTTP spec is
affirmative on which headers cant contain values separated by commas.
see list at end
> Returning whatever was found in the original request is IMO the only
> reasonable solution. I doesn't think apache ( or other servers )
> are spliting/merging received headers either.
>
I'm looking at httpd. It looks like it does merge received headers. That is,
Accept-Language:A, Accept-Language:B gets combined into Accept-Language:A,B.
Then ap_table_get() returns a single string, with all of the values. There is
no API equivalent to getHeaders().
> The user application should use getHeaders() and split each header ( or
> merge them ) if it knows a header is multi-value.
>
> Well, there is a trick that can be used in deciding to split/merge:
> if the user calls getHeader("Foo"), and we have multiple Foo headers,
> then we can concatenate them and return the result.
>
That seems to be, effectively, what httpd does.
> If the user calls getHeaders("Foo") and we have headers with ',', then
> we split them. ( if he would call getHeaders("Date") - it would be
> his error ).
>
> However that's a bad solutuion - many apps call getHeaders() for
> all headers ( like request dump, etc ).
>
> Costin
Headers which can have a list of values, according to RFC 2616:
Accept
Accept-Charset
Accept-Encoding
Accept-Language
Accept-Ranges
Allow
Cache-Control
Connection
Content-Encoding
Content-Language
Expect
If-Match
If-None-Match
Pragma
Proxy-Authenticate
TE
Trailer
Transfer-Encoding
Upgrade
Vary
Via
Warning
WWW-Authenticate
Accept-Ranges, Vary and WWW-Authenticate are response headers, and should not
be part of a request.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
