We've encountered a rather odd/hard-to-nail down issue when integrating a
.NET client to a SOAP-based webservice in Glassfish 3.0.1.
There's a known issue with the way .NET clients have implemented
expectations/continuations for HTTP 1.1 with basic auth - essentially they
just pass along the request body before getting the 401 or the 100-continue.
It seems like, on the Glassfish side, it eventually results in a 505 HTTP
version not supported. I am guessing that initially GF must close the
connection but as the system stays up, longer, there must be some latency and
it tries to process the body of the post as a second HTTP post (which,
obviously doesn't have the header with the HTTP version).
I have found documentation on JBoss and Tomcat workarounds which involve
either (a) disabling keep alive, or (b) adding .NET user-agent regex to
restricted-user-agents to force HTTP 1.0.
I've been trying to essentially downgrade the network listeners on GF to
HTTP/1.0, but to no avail. I have Fiddler set up as a reverse proxy, locally,
so I can see what HTTP posts are coming through from the .NET client, and
it's always 1.1 and GF services the requests. I would have expected GF to at
least return a 505 - version not supported, if I'm setting the listener http
version to HTTP/1.0. But it just takes the 1.1. Does GF just ignore that
version setting?
--
[Message sent by forum member 'cgelinas']
View Post: http://forums.java.net/node/821137