Join the AMA (Ask Me Anything) with the Firefox leadership team to celebrate Firefox 20th anniversary and discuss Firefox’s future on Mozilla Connect. Mark your calendar on Thursday, November 14, 18:00 - 20:00 UTC!

This site will have limited functionality while we undergo maintenance to improve your experience. If an article doesn't solve your issue and you want to ask a question, we have our support community waiting to help you at @FirefoxSupport on Twitter and/r/firefox on Reddit.

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

WInsock Accept/Receive picks up same request a second time when responding with Binary data to Firefox

  • 14 پاسخ
  • 1 has this problem
  • 4 views
  • آخرین پاسخ توسّط jtaylorme

more options

I have a simple webservice that sits and listens for requests. These requests may be for a HTML, JSON, XML, Binary (usually images), etc response. What I have discovered is that when a Binary request is made, fulfills the request and then checks for the next request it picks up the same request, this is very consistent behavior. This doesn't happen when the request is for HTML or XML. Everything works fine except my service is doing double-duty. All the response codes are good, no errors. The webbrowser only sees the response from the first "send", or at least it does nothing with the second. This happens with blocking or no-blocking. There is a minor difference in the "recvd" data and it appears to be slight corruption in the last two lines on the second time.

I originally created the webservice with winsock tools that come with my development language and then wrote my own since I needed to bind to a specific adapter and those tools wouldn't. I then "evaluated" another set of Winsock tools. I see the same behavior in all three. Not sure what would be different about the Binary responses and Firefox that would cause such behavior. When I query the webservice via IE I don't have this problem.

Suggestions?

Thanks.

Jim

I have a simple webservice that sits and listens for requests. These requests may be for a HTML, JSON, XML, Binary (usually images), etc response. What I have discovered is that when a Binary request is made, fulfills the request and then checks for the next request it picks up the same request, this is very consistent behavior. This doesn't happen when the request is for HTML or XML. Everything works fine except my service is doing double-duty. All the response codes are good, no errors. The webbrowser only sees the response from the first "send", or at least it does nothing with the second. This happens with blocking or no-blocking. There is a minor difference in the "recvd" data and it appears to be slight corruption in the last two lines on the second time. I originally created the webservice with winsock tools that come with my development language and then wrote my own since I needed to bind to a specific adapter and those tools wouldn't. I then "evaluated" another set of Winsock tools. I see the same behavior in all three. Not sure what would be different about the Binary responses and Firefox that would cause such behavior. When I query the webservice via IE I don't have this problem. Suggestions? Thanks. Jim

Modified by jtaylorme

All Replies (14)

more options

Double-requests have been reported when the character encoding of text/html documents was not specified in the HTTP headers and the encoding in the meta tag in the page did not match the user's default. But this does not sound applicable to images or other non-textual content.

If you watch the browser's requests with Firebug or an external proxy such as Fiddler, are the two requests sent basically at the same time, or is there a predictable interval between them?

In case an add-on or custom setting is involved, could you test in a clean profile? Close Firefox and start up in the Profile Manager as described in Profile Manager - Create, remove or switch Firefox profiles. When you want to switch profiles, close Firefox and return to this dialog. Any difference?

more options

Following is a sample of what I send preceding the content in case that is useful. Using Wireshark the second request was the third packet after the first so it is an immediate thing following the first. From an observation perspective, there is no pause, it loops fulfilling the first request and checks the next request and always, immediately, finds it repeated, when using Firefox.

HTTP/1.1 200 OK
Date: Thu, 08 Nov 2012 19:00:56 GMT
Expires: Thu, 08 Nov 2012 19:00:56 GMT
Content-Type: image/jpg
Content-Length: 5106

I'm also attaching the images of the requests so you can see the minor corruption in the last two lines. Would have done that earlier but didn't see any way to do that before.

I'll give your suggestion a try and report back. Thanks for the reply.

Jim

Modified by jtaylorme

more options

Same thing. Only difference is that the "Cache-control" line at the bottom of the images I posted doesn't appear as part of the request.

Jim

more options

How is the request generated -- a tag (image, object, iframe, etc.), script object (e.g., new Image), XMLHttpRequest, or some other way? Perhaps we should take a quick look at any code in case we can spot any Firefox-specific gotchas.

more options

It varies...in trying to track this down I've just been doing something like

http://my_domain.com/hello/hello.htm

from the address bar

Another case that I use in production...

<iframe name="webservices" src="http://my_domain.com:17073/?profile=MyProfile&method=my_item&keyword1=4271303" width="100%" height="467">
Your browser does not support inline frames or is currently configured not to display inline frames.
</iframe>


Thanks again.

Jim

Modified by cor-el

more options

I have a PHP script that returns image/jpeg, but from what I can see, the requests are not sent twice (testing Fx17 beta on Windows 7 Pro x64 with a script running on an Apache server). I'm running out of ideas.

more options

So your PHP script is watching a port and reading the request off that socket and then sending back an image in response?

Yeah...I'm running out of ideas too. It is like the queue isn't being update properly and that request is still sitting there so it is picked up again on the next Accept().

Appreciate your time. I can live with it, if needed, as it works fine apart from the extra work on the service and the minor corruption in the second request may give me a hook to avoid the double-processing.

Thanks again.

Jim

Modified by jtaylorme

more options

Actually, my PHP script is running under Apache; I have no idea how to listen on a port directly. I assumed the browser is agnostic as to the program listening on the other end, but there might be a difference. It's possible that Apache is filtering out a second request so I don't see it in the webserver logs, or is doing something just a bit different with the connection than your program.

more options

Hard to say...would think it was just me except I've tried three different set of Winsock tools and see the same behavior...still doesn't mean it isn't still me but I have high hopes of it not being my fault :-)

Thanks again. If I figure it out I'll post the answer.

Jim

more options

You might have done the following and just not mentioned it originally. Have you tested using Firefox from any PCs that aren't outfitted with as many developer tools? It could be that the new profile test didn't really bypass everything.

more options

Found the problem...in the Binary response below the Content-Type I had a blank line. Once that was removed the problem went away....BUT of course now IE doesn't like it with that line removed...AAAARRRRRGGGGGGGHHHHH!!!!

Oh well, I'll stop bothering folks here now that I know what is causing the problem.

Thanks.

Jim

more options

Yes. It seems to happen from any firefox browser.

Jim

more options

Actually, I think there should be a separation between the headers and the content. If you retrieve ordinary image files from web servers and check the packets in Wireshark, hopefully you can find the precise combination of characters that makes all browsers happy.

more options

I agree...that was my thought as well...just had a momentary happy period when I thought I had solved the problem.

Jim

Modified by jtaylorme