Closed
Bug 535239
Opened 15 years ago
Closed 13 years ago
Firefox Adobe addon sending consecutive request to the server.
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: brijessi, Unassigned)
Details
(Whiteboard: [CLOSEME 2011-1-30])
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 We have deployed few reports(.pdf) on our internal website. User initiates the request for these pdf they are intermittently working on Firefox. On Debugging with Tamper Data, Firefox is initiating another request before the 1st is completed. Since the second request is initiated by Firefox without appropriate headers and it fails. I'm attaching all the request headers. 1st Request Headers:- GET /epsvcs/view/company/ivtxReport/id/%7Bivtx:gateway/IPDocId=15396467/PubDate=20091016/Pages=11%7D?media=pdf HTTP/1.1 Host: XYZ.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 X-REMOTE-EMGSESSIONID: 27137ZzZKJHEQT2CAAAGUAIAAAAAATRKAAAAAABSGAYDSMJSGE2TCMBRGQ2TIMRT Cache-Control: max-stale=0 Connection: Keep-Alive X-BlueCoat-Via: 2A6B8D6EEDEB06F1 1st Response:- HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Date: Tue, 15 Dec 2009 15:46:07 GMT Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept Accept-Ranges: bytes Server: Noelios-Restlet-Engine/1.1.5 Content-Type: application/pdf Content-Length: 280949 2nd Request and Response:- GET /ep_svcs/view/company/ivtxReport/id/%7Bivtx:gateway/IPDocId=15396467/PubDate=20091016/Pages=11%7D?media=pdf HTTP/1.1 Host: XYZ.COM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Range: bytes=24314-280948,24314-24315 Cache-Control: max-stale=0 Connection: Keep-Alive X-BlueCoat-Via: 2A6B8D6EEDEB06F1 Response:- HTTP/1.1 501 Not Implemented Server: Apache-Coyote/1.1 Date: Tue, 15 Dec 2009 15:46:14 GMT Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept Accept-Ranges: bytes Server: Noelios-Restlet-Engine/1.1.5 Content-Type: text/html;charset=ISO-8859-1 Content-Length: 349 Connection: close Reproducible: Sometimes Actual Results: mentioned above IE has no problem opening the PDF and If I change the Firefox association to Adobe installed on the box, it works fine i.e. when I changed in Option-> Applications-> ContentType & Action ( Use adobe reader 9.1 default) it works fine. Its not working with 'Use Adobe Acrobat in Firefox'. I'll be more than happy to provide the tcpip logs.
Comment 1•15 years ago
|
||
Where does the X-REMOTE-EMGSESSIONID: header get added? Is that added by a proxy? Is this being downloaded by some Ajax-y site using XMLHttpRequest? I have no idea why the second request is a byte-range request, maybe we do that in certain error cases? (I'd have to ask our networking guys.) But your server announced "Accept-Ranges: bytes" in the first response so it shouldn't have failed with a 501-NotImplemented. Is your server falsely advertising byte range support? Or am I misinterpreting the 501? maybe it's being used like a 401 except since it's a custom authentication header you can reply with the standard unauthorized status. Is the problem the lack of the X-REMOTE-EMGSESSIONID: header in the second request? You weren't very specific about what you thought the appropriate headers were, and for normal http traffic what I see looks perfectly fine.
Reporter | ||
Comment 2•15 years ago
|
||
IE Success TCP Log.
Reporter | ||
Comment 3•15 years ago
|
||
Failure to load pdf in Firefox, attached TCP data.
Comment 4•14 years ago
|
||
Reporter, are you still seeing this issue with Firefox 3.6.13 or later in safe mode? If not, please close. These links can help you in your testing. http://support.mozilla.com/kb/Safe+Mode http://support.mozilla.com/kb/Managing+profiles You can also try to reproduce in Firefox 4 Beta 8 or later, there are many improvements in the new version, http://www.mozilla.com/en-US/firefox/all-beta.html
Whiteboard: [CLOSEME 2011-1-30]
Comment 5•13 years ago
|
||
No reply, INCOMPLETE. Please retest with Firefox 3.6.13 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•