WInsock Accept/Receive picks up same request a second time when responding with Binary data to Firefox
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
Wot jtaylorme
Wšě wotmołwy (14)
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?
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
Wot jtaylorme
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
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.
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
Wot cor-el
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.
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
Wot jtaylorme
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.
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
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.
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
Yes. It seems to happen from any firefox browser.
Jim
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.
I agree...that was my thought as well...just had a momentary happy period when I thought I had solved the problem.
Jim
Wot jtaylorme