For some unknown reason, I found out that MSIE 6.0 with SP 1 not including the cummulative patch released on April 2003 send duplicate post requests for any jsp page. I use IIS with Jakarta ISAPI dll. tomcat version is 4.1.24. I found out when trying to debug intermittent server not found errors for a jsp page where i know the server is up and running and connection is fine. I used TCP trace Etheral where I found out that IE is always posting two identical requests except for the HTTP_REFERER header. After double checking IIS logs I found out that this is correct where there are lots of duplicate enteries. It is not an IE bug because the request comes fine to regular asp pages running on the same server. This bug is very annoying and completely unpredicatable. Havent' noticed it much with IE 5.5 or IE 5.0
Any body has an idea about this bug?
Could you please post a test case (URL/html) which posts twice? I've been developing heavily for IE 6 and haven't found anything to that matter. Also, are you certain there's nothing wrong with the way the form itself is built?
The problem with the form was just the way I found out about the problem. But actually the problem itself is persistent, even on get requests. It seems like all IE 6 Sp 1 (without the latest cummulative patch ) clients that is accessing Tomcat are doing duplicate requests. I think it has something to do with the Jakarta ISAPI.dll that might be the problem. Something to mention is I have a CompressIt plugin installed for IIS but i don't think that can cause any problems. it doesn't with asp pages at least.
Strange indeed, have you tried doing an HTTP GET manually using telnet? The only thing I can think of, is that somehow IE must be convinced that the HTTP connection wasn't established correctly. Try the following: telnet [servername] 80\n GET /[something.jsp] HTTP/1.1\n Host: [servername]\n \n \n Now compare the results from your ASP pages and your JSP pages. If there's a significant difference please post it back. Another thing to try is to have tomcat run standalone as well on port 8080 and check whether the problem persists (probably not, but at least that places the problem with the coupling between Tomcat and IIS)
I followed what you have requested and here is the difference between the two For IIS alone GET /admin/account.asp HTTP/1.1 302 Object moved Server: Microsoft-IIS/5.0 Date: Mon, 09 Jun 2003 18:07:44 GMT Location: ../index.shtml Connection: Keep-Alive Content-Length: 135 Content-Type: text/html Set-Cookie: ASPSESSIONIDQQGGQLVQ=NPMOPHDBBEPJAHDCPICDGOBA; path=/ Cache-control: private <head><title>Object moved</title></head> <body><h1>Object Moved</h1>This object may be found <a HREF="../index.shtml">here</a>.</body> And for IIS with Tomcat it is GET /jsp/calendar/calendar.jsp HTTP/1.1 302 Server: Microsoft-IIS/5.0 Date: Mon, 09 Jun 2003 18:06:56 GMT Set-Cookie: JSESSIONID=BC7C3F989CA9E8447B631260657A5304; Path=/jsp Location: http://www.brainfuse.com Content-Type: text/html;charset=ISO-8859-1 Content-Length: 0 One of the few things to notice is : 1. There is response message after the response code from IIS with Tomcat 2. There is no Connection:Keep Alive flag 3. the cookie is pointing to /jsp not to / Aparently this problem has been eliminated after I installed the latest IE cummulative patches from microsoft. But the problem is what about all these other clients that are having Win XP and IE 6.0 that DONOT upgrade. Let me know what you guys think?
I executed the test again with a page that doesn't require login in: Here are the results from IIS: HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Mon, 09 Jun 2003 18:31:58 GMT Connection: Keep-Alive Content-Length: 12348 Content-Type: text/html Set-Cookie: ASPSESSIONIDQQGGQLVQ=ABNOPHDBFFOGJKPNOKEPCEJJ; path=/ Cache-control: private Page content goes here just html Here are the results from Tomcat as ISAPI plugin: GET /jsp/index.jsp HTTP/1.1 200 Server: Microsoft-IIS/5.0 Date: Mon, 09 Jun 2003 18:32:20 GMT Set-Cookie: JSESSIONID=2BB72CC543D77619DA8376588DC0A800; Path=/jsp Content-Type: text/html;charset=ISO-8859-1 Page content goes here just html And here are the results from Tomcat as Standalone: GET /jsp/index.jsp <!doctype html public "-//w3c//dtd html 4.0 transitional//en" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html> You will notice when Tomcat as ISAPI, 1. There is no response code ( I don't think it is a big deal. ) 2. there is no Content Length ( I think this is a big one ) . 3. The Content Type is different there is character set appended. 4. The Keep Alive flag is not there. When using Tomcat as a standanlone, there are no headers what so ever, I am not sure why but this is the case.
A few things: - There IS a response code sent with ISAPI. This would cause trouble, but doesn't since it is there. (The standard OK is an arbitrary string and not required) - The Content length is REQUIRED by the HTTP/1.1 spec. There's a high likeness this would cause trouble with some browsers. - The Connection keep-alive missing header only signifies that the browser will have to make a new connection for every resource. That's no problem. - The charset is allowed but not required for as far as I know. I've tried my own install of tomcat for some resources standalone and all headers are nicely sent back. However this is with Tomcat 4.1.18 not like your 4.1.24. I don't have the time to upgrade my system and the problem doesn't exist with Tomcat standalone, so I'll skip that. I think a Tomcat expert will need to examine this info to see if the problem with the missing content-length always occurs with the ISAPI plugin and if this is the source of the problem. I am not that expert, I only know a little about the HTTP spec and browser/server traffic. Turning this over to anyone who'll take it...
How can I change the page so that it tells the content length even though it is dynamic. The only way I would think of is to add everything into a StringBuffer and then calculate the stringbuffer. There must be an easier way. Somebody Please help.
That's explicitly NOT the job of the web developer but one of the servlet container. I reckon there must be some problem with either the ISAPI plugin or with that specific version of Tomcat. As said before this will have to be looked into by one of the Tomcat developers.
Ok, I'm not a Windows developer, so I have no clue about the IIS version of mod_jk. However, your tests are flawed if you want someone that could understand the issues to look at this. Firstly, you should test with including a protocol: GET /jsp/calendar/calendar.jsp HTTP/1.0 Even better if you can test with HTTP/1.1 and include a Host header. Most of the differences you've documented are due to Tomcat thinking that your client doesn't even speak the HTTP/1.0 protocol, and so is trying to talk down to you.
I think there were an IE problem that was fixed by the Feburary 2003 update, the issue seems to be related to this bug 329802 BUG: Proxy Authentication Through IAuthenticate May Fail on Secure URL http://support.microsoft.com/default.aspx?scid=kb;EN-US;329802 The only thing is I can't see how they are related, the symptoms are the same and the fix for the problem described fixes that problem that I had with my IE. But the only explanation is that mod_jk acts as a proxy or even IIS acts as a proxy. The problem described is an issue only if the application is using IAuthenticate interface. Neither the jsp pages or isapi deal with that if I am correct. So now the question is why MSIE thinks of mod_jk or IIS as a proxy, and if there is any work arounds. This is a significant problem with IIS and MSIE 6 SP 1 which was published by MS on all XP machines sold in the past year or so. Imagine if you are doing a purchase you are paying for your items with a credit card and all of a sudden IE shows dns error. Any work around would be appreciated.
Any one is having this problem, I have noticed it on more than one machine so far.
I think this bug is the problem. this is very critical issue ladies and gentleman. Can any body tell me the last version that doesn't have this bug and works with AJP 1.3 *** This bug has been marked as a duplicate of 15278 ***
I had the same problem with a self-written webserver. Duplicate requests occured in the following cases: - POSTs with multiple of 2047 bytes of data - the response is written back before all data from the input stream is read - the response has a certain length. I think that the request length header sent by MSIE does not contain the last CR LF. When I read these bytes too, I had no problems anymore. P.S.:With UTF-8 encoded pages the troubles occured more often.
Do you have any suggestions how can I fix that on Tomcat?
Do you have a test case like a jsp page that does this kind of post so that i can find a work around, I tried to create one but it is very hard to replicate, I am working on a mission critical system that cannot tolerate this kind of error. Also regarding your comments, you mean IE doesn't send the content length in each of the scenarios that you mentioned? Some of these scenarios seems to be dependant on each other like - the response is written back before all data from the input stream is read. Why would the webserver do that? is because of the first case? P.S. I have been going back and forth about this bug for almost four month any help would be greatly appreciated?
Do you think if I use something like Orielley servlet package to read the request input stream that might be better. Thanks in advance
Hi! (Sorry for the long delay) I'm sorry, but I can't send you an example: it is in our product, which is a web based management system. There is one page which always produces the fault. I tried to extract it, but when it is not used in the frameset, the error doesn't occur?!?! To your question: The webservers read up to the reported content length. The IE SOMETIMES(!) adds a CRLF that does not contribute to that length. Depending on request length, buffers, and maybe the network the IE considers that data as sent or not. If not, it complains about a response (and sends the request a second time). I had problems again, since I used a plain InputStream and trying to read the 2 unreported characters (CRLF) hanged up my application, since sometimes they are not there. So what I do now, i that I create a buffer of <cont-length>+2 bytes size and do a read with that array. If the characters are there, they are read, if not, I see it in the return value of my read. But I did that in my web server. If you use Tomcat, then you don't have direct control over that part. But what if you use the ServletInputStream to parse the post data yourself? This might work in Servlets, but in JSPs it might be tricky. I don't know the O'Reilly package so I can't help you on that. So my suggestion would be that you try a read (with timeout!) on the InputStream if you can get access and consume the left bytes. Jürgen
As anyone tried a different browser