-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
André Warnier wrote:
| A-prioris :
| - Some HTTP headers may occur several times in an HTTP request.
| - According to the HTTP 1.1 RFC, HTTP headers names are
| case-insensitive, and "Accept-charset:", "ACCEPT-CHARSET:",
| "Accept-Charset:" are thus equivalent.
|
| 1) The ServletHttpRequest.getHeaderNames() method returns an Enumeration
| (of request header name strings).
|
| Does getHeaderNames() always "fold" equivalent HTTP headers of the same
| name into one single entry, or can it happen that the Enumeration
| contains the same name several times ?
Neither the servlet API nor the servlet specification say either way.
Whenever this happens, you should treat it as (obviously!) ambiguous and
therefore container-dependent. I can imagine implementations could go
either way: collapse all header values together for the same header name
(because request.getHeaders() needs to return them all at once) or leave
them separate because it is less work than collapsing them. I would
imagine that the performance of each strategy is heavily dependent upon
the specifics on the web application in question, so it's hard for
implementors to decide which strategy to use.
Another caveat: since the decision is left to the servlet container
implementors, different versions of the same container could implement
different strategies.
The good thing about this ambiguity, since you are writing your own
implementation, is that you get to choose the behavior, and so you can
choose whatever is easiest for you to implement.
| What when there are two request headers with essentially the same name,
| but varying in the "case" of the header name in the original request ?
| Like
| Accept-charset:
| Accept-Charset:
| Does .getHeaderNames() then return one single entry for both of the
| above, or two ? and if only one, which of the above "spellings" would it
| return ?
Again, since the spec does not specify the behavior, all you have to do
is meet the (minimum) requirements laid out by the specification.
| 2) (may overlap the above) Does Tomcat fold the header names internally
| to upper- or lower-case ?
You'll have to check the code yourself ;)
| 3) the ServletHttpRequest.getHeader(string name) also returns an
| Enumeration (of header string values).
No, it returns a String. I think you meant getHeaders(String name). I'm
moving forward with that assumption.
| Do .getHeaders("abc"), and .getHeaders("ABC") always return the same
| Enumeration?
In the sense that they will contain the same values, yes. I wouldn't bet
that request.getHeaders("abc") == request.getHeaders("ABC") because the
objects are likely to be created on the fly. I /would/ bet that
request.getHeaders("abc").equals(request.getHeader("ABC")), though.
| In other words, is it guaranteed that with one call, the Enumeration
| returned contains all values of all HTTP headers having that name,
| independently of the original header's case and independently of how the
| parameter "name" is passed ?
Exactly. The servlet API for getHeaders() states: "The header name is
case insensitive."
| 3) Is the above implementation-dependent (e.g. Tomcat vs Websphere), or
| is it an essential part of the servlet specification, which can be
| relied upon to work under any servlet container?
The only things upon which you can rely are those explicitly stated in
the servlet specification (or the servlet API docs, which is actually a
subset of the servlet specification).
I would highly recommend acquiring a copy of the servlet specification
and reading through the relevant parts. It's quite readable, actually.
Make sure you get the latest version applicable to your container (TC
4.1 => 2.3, TC 5/5.5 => 2.4, TC 6 => 2.5).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkigTLgACgkQ9CaO5/Lv0PBqTgCbBnEUH95XFq81f59zmbCIJ8rl
uWQAniKEeQIQHdQOHzkw46ASi5caXmd8
=+l00
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
