Has there been any progress on this issue? Would it help if I created a source patch that would fix this issue?

What would help is to provide examples of the Accept header on the wire and how it's returned by the HttpServletRequest. Is this behavior specific to iPlanet WebServer version 7?

Re-classifying from Bug to Improvement.

Rossen,

I disagree that this should be classified as an improvement. The servlet spec "http://docs.oracle.com/javaee/5/api/javax/servlet/http/HttpServletRequest.html#getHeaders%28java.lang.String%29" states that "Some headers, such as Accept-Language can be sent by clients as several headers each with a different value rather than sending the header as a comma separated list.".

That is what is happening in this case. Tomcat returns a single accept header as a comma separated string. Iplanet returns a separate accept header for each accept value passed over. I debugged the ServletServerHttpRequest.getHeaders() method and captured the results from line 95 of this class.

Here are the results:

tomcat -> The enumeration returns one value of "text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8".

iplanet -> The enumeration returns 4 values ["text/html","application/xhtml+xml","application/xml;q=0.9","*/*;q=0.8"]

This is causing us major issues because the HttpHeaders.getAccept() is only ever returning the "text/html" entry on iPlanet.

I am not sure that interpretation is accurate. Here is a quote from the Servlet specification that is a little more clear than the Javadoc:

The getHeader method returns a header given the name of the header.
There can be multiple headers with the same name, e.g. Cache-Control
headers, in an HTTP request. If there are multiple headers with the
same name, the getHeader method returns the first header in the
request. The getHeaders method allows access to all the header values
associated with a particular header name, returning an Enumeration
of String objects.

The key cases are multiple headers with the same name or one header with comma-separated values. Even in the Javadoc it is phrased as an either-or proprosition: "several headers each with a different value rather than sending the header as a comma separated list."

This is why I asked for what you see on the wire (with Firebug, Chrome dev tools, etc). I suspect it is a single header with a comma-separated list of media types that iPlanet is parsing. If that is the case we will consider it an improvement, or something extra we do to make sure it works on iPlanet.

Sorry, I misunderstood what you were asking for. I used firebug to look at the headers and sure enough there is only use accept header.

The value is "text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8".

Looks like Iplanet is parsing the header into multiple entries on our behalf (why, oh why do they do that?). The funny thing is that I believe Iplanet is running tomcat under the covers.

Just another reason why I want to move away from Iplanet.

Do you know of any work around to be able to get all the header values?

Ok, good to know.

Well, you could create a Filter that wraps the request and returns the Accept header value as a comma-separated String. As long as that doesn't impact any other code that relies on the iPlanet behavior, that should work. Another other option is to patch HttpHeaders temporarily (until this issue is resolved), for example by copying it to your source directory, preserving the package name, and modify it.

Here is a patch I made that resolves the issue:

public List<MediaType> getAccept() {

    String value = null;
    List<String> headerValues = headers.get(ACCEPT);

    if (headerValues != null && headerValues.size() > 0) {
        if (headerValues.size() == 1) {
            value = headerValues.get(0);
        }
        else if (headerValues.size() > 1) {
            value = StringUtils.collectionToCommaDelimitedString(headerValues);
        }
    }

    return (value != null ? MediaType.parseMediaTypes(value) : Collections.<MediaType>emptyList());
}