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]>