Here is the customer's problem

> One of my customershas an issue with cookies on IE on Windows. I've tried vari
ous aliases for help, but had little success. Mary McCarthy referred me to you.
Perhaps you can help me with my cookie problem.
>
> The customer reports problems with cookies when the browser is IE. Due to corp
orate policy, IE is the only browser they use. They are using 1.4.2_10.
>
> Log has the following error.
>
> Uncaught error fetching image:
> java.lang.IllegalArgumentException: Illegal character(s) in message header value: SITESERVER=ID=bfe5bedac5ef5c6553da6037e6
> ....
> DQo8L3NhbWw6QXNzZXJ0aW9uPg==_null
>
>     at sun.net.www.protocol.http.HttpURLConnection.checkMessageHeader(Unknown Source)
>     at sun.net.www.protocol.http.HttpURLConnection.addRequestProperty(Unknown Source)
>     at sun.plugin.net.protocol.http.HttpURLConnection.connectSetup(Unknown Source)
>     at sun.plugin.net.protocol.http.HttpURLConnection.connect(Unknown Source)
>     at sun.plugin.net.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
>     at sun.awt.image.URLImageSource.getDecoder(Unknown Source)
>     at sun.awt.image.InputStreamImageSource.doFetch(Unknown Source)
>     at sun.awt.image.ImageFetcher.fetchloop(Unknown Source)
>     at sun.awt.image.ImageFetcher.run(Unknown Source)
>
> Discovered problem occurs when request header exceeds 4k. When that happens, junk characters are added to the request header in place of the last cookie. Customer reports that roughly 1% of these junk characters are LFs. And when the LFs are not followed by a SPACE or a TAB, the java.lang.IllegalArgumentException is thrown.
>
> Since most of the cookies are not needed by this one application, I referred cu to rfc2965. Specifically, section 3.3.4 Sending Cookies to the Origin Server says
>
>    Domain Selection
>       The origin server's effective host name MUST domain-match the
>       Domain attribute of the cookie.
>
>    Port Selection
>       There are three possible behaviors, depending on the Port
>       attribute in the Set-Cookie2 response header:
>
>       1. By default (no Port attribute), the cookie MAY be sent to any
>          port.
>
>       2. If the attribute is present but has no value (e.g., Port), the
>          cookie MUST only be sent to the request-port it was received
>          from.
>
>       3. If the attribute has a port-list, the cookie MUST only be
>          returned if the new request-port is one of those listed in
>          port-list.
>
> I asked cu to use this to just include the cookies they are interested in. They replied that IE does not comply with rfc2965. It only complies with RFC 2109.
>
> Cu asks the following questions. Can anyone help me with these?
>
> 1. As the issue at hand is at the interface of the Java plug-in and Microsoft IE, it would be useful for Sun to provide one of two things:
>
> 1.a. identify the interface point at which the plug-in HTTP handler obtains the cookies from Microsoft IE, or
>
> 1.b. provide a Win32 binary (instantiable in IE 6 via an OBJECT tag) that could probe
the same interface point in 5.a, and expose a new interface point that would provide transparently the results obtained through the first interface.  This approach would permit Sun to keep the knowledge of the actual interface private.
>
> 2. If they upgrade to 5.0, can they use the CookieHandler class to add just the one cookie they need to the request header and discard all others?
>
> 3. It is unclear to me if this is possible. I see in 6.0, there is a CookieManager class which would do this. Is this so?


here is a response from a Sun cookie engineer

When I glanced at the stack trace and saw HttpURLConnection, I initially assumed
it was a java.net problem, but as I looked further down and saw an issue that re
lates to buffer sizes, then that would often point to native code problems rather than a bug in Java code.

I took a quick look at the plugin win32 (IE) cookie interface native code, and t
here does appear to be a problem there. The native code is calling the wininet InternetGetCookie() function with a fixed buffer size of 4K. The return value is not being checked, and (this is a common API paradigm in win32), the specific case where the supplied buffer is too small, results in an error being returned, where the caller is supposed to call the function again with a larger buffer. Instead, the buffer is being returned with whatever junk happens to be on the stack at the time.

This code is essentially the same on 1.4.2 and later releases (though it is located in different source files). I suspect this is the problem that the customer is seeing.