I think the relevant section is 4.2 - and it says:
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.
So getHeader() can ( and probably should ) return the concatenated values.
getHeaders() is a different story - I don't think it can or should
take single-line headers and split it.
It seems the spec defines all extension headers as 'entity headers', but
I don't see where it specifies that entity headers can't be multi-value.
extension-header = message-header
It does say that multiple headers with the same name are allowed only
if they are defined as 'comma-separated', but I can't find where it says
that the list of comma-separated is the restricted to the headers
in the spec ( i.e. extension headers can't be defined as
'comma-separated').
My understanding is that you can define 'Foo' header with content
beeing comma-separated multi value.
Tomcat can only merge headers with the same name ( since it is
safe ). getHeader() will return maximum of information - and if
the user wants to know the 'original' format he can use getHeaders()
Costin
On Sun, 18 Aug 2002, Steve Downey wrote:
> 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]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
