Miguel Figueiredo wrote: > > > Hello Edmund, > > > > That problem is similar with one I saw in this mailing list some months >ago. In short, it's an M$ problem in obeying HTTP specification, and >stubbornness of tomcat's team to follow a slightly different behaviour where >HTTP spec is kind of shallow. > > > > If it is what I'm thinking, it's a problem with the interpretation of the >expect-continue http header witch, M$ sends to the server, but instead of >waiting for de 100-continue response, it just starts to send the body of the >message. When the server receives the request with expect header, and it's >body, the server thinks the body is another HTTP request, witch obviously is >not. Result: server returns PROTOCOL_NOT_SUPPORTED http code. > > > > How to solve this? Turn off expect-header in M$ side or keep-alive >connections (auch). > > > > Hope this helps, > > Miguel Figueiredo > > > > Thanks, Miguel.
I've been doing some packet sniffing now to see what's really going on. It does not look like the problem you described - at least to me it does not. the server just gets these 4 requests (server URL is http://halley.liland.org:8081/slide/): 1. OPTIONS / HTTP/1.1 answered with status 200 2. GET /_vti_inf.html HTTP/1.1 answered with 404 3. POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1 again 404 (what is the client attempting to do here????) 4. OPTIONS /slide HTTP/1.1 answered with 302 (redirect from "/slide" to "/slide/") that's it. nothing more from the client after it receives the redirect. what's really sad: not one of these requests even reaches Slide. Edmund --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
