HTTP 100 being treated wrong?

A project I am working on was getting a socketClosedException so when doing a packet trace we saw that the last packet before the exception was an HTTP 100. We noticed it was using IIS 5.1 when previous testing had been done on IIS 6.0.

As a test, we tried using jrockit, which was being using in another project and has IIS 6.0 associated with it, and we found that it was sending the HTTP 200 with not HTTP100. which did not create an exception and the program proceeded properly.

The confusion here is that it looks as though when it recieved the continue, it interpreted that as something else and caused it to close prematurely thus giving the SocketClosedException. Is there any known issue with an HTTP 100 being treated wrong?

The agents are using Java 1.5.0_04.

Hopefully this isn't too vague.

Thanks

[851 byte] By [mdwarnera] at [2007-11-15]
# 1

These forums arn't letting me edit right now so I'm going to fix my errors in this reponse.

Disregard the 2nd paragraph as it really doesn't make any sense I got messed up while writing it and relating different tests, but the problem itself doesn't change.

We're still using IIS 5.1 because our host did not changed. When we switched to jrocket (BEA's Java) we did get an HTTP100 followed by an HTTP200 without any exceptions. This tells us that Sun's Java was interpreting the HTTP100 differently than BEA's.

Hopefully this clarrifies things, I will try to edit the main post with this later to eliminate the misunderstanding I had.

mdwarnera at 2007-7-12 > top of java,Core,Core APIs...
# 2

Yeah. I don't really understand what your actual problem is.

So I'll just talk about 100 instead. 100 is not an error condition but a signal from the server that the client should continue sending the request.

It might be worth noting that a 100 request should not be sent to a 1.0 client. That would be an error condition.

cotton.ma at 2007-7-12 > top of java,Core,Core APIs...
# 3

We know it's not an error condition which is why there's a problem.

When the 100 is recieved while using BEA's JVM (JRockit), the program works as it should, but when we change our JVM to Sun's, recieving the 100 causes the exception. This tells me that there is something different about how the 100 is being recieved, processed or handled by Sun's JVM.

I'm not sure if there is necessarily a bug somewhere (presumably on Sun's end because it works with JRockit) or if there is something fundamental that we are missing with HTTP messages that Sun handles differently somehow.

I think this makes the question/problem clearer since it's not split into two posts.

mdwarnera at 2007-7-12 > top of java,Core,Core APIs...
# 4

What HTTP level does Sun say it is though? If it is 1.0 then the server is at fault for sending a 1.1 message back.

I'd look at that first. Because what it means is that okay Sun whatever blows up when it sees the 100 but depending on what protocol level is used this could be the correct behaviour.

Also what is the exact error message you are seeing?

cotton.ma at 2007-7-12 > top of java,Core,Core APIs...