Chrome GET request cancels and restarts continously - ajax

I am trying to play an mp4 video on my website using window.location = path-to-file/file-name.mp4 through Chrome. Although the video plays, Chrome Developer Tools Network tab shows that that the request continuously gets cancelled and resent:
.
I have left the Developer Tools window open and it has shown that more than 5000 requests have been made and over 600 MB transferred :
It's beyond me why this is happening. I have tried looking at the the request and response headers for the first 4 requests to see if I could spot something obvious (I am by no means an expert):
and the only thing I can see is that the RANGE and CONTENT-RANGE in the request and response headers, respectively, seems to be changing. I also noticed that the very first response has TRANSFER-ENCODING set to CHUNKED.
I tried researching these terms but was not able to come to any conclusions (except the one that I still have a lot to learn, haha). If anyone could please provide any help or point me in the right direction I would be most appreciative :)
Thanks for your help!
EDIT : I would like to add that I am not explicitly creating a GET request with XMLHttpRequest, just using window.location to play the video in a new window.

Related

Chrome XmlHttpRequest Hanging

When I make a XmlHttpRequest (via jQuery's $.ajax) to a particular URL, my Chrome consistently hangs every time with a status on the request of 'Pending'.
After that Chrome must be closed ie. forcibly from Task Manager, and it exhibits general signs of mayhem such as the Cookies and Scripts tabs being empty when they were full of normal looking data immediately prior.
This is odd because (a) my coworkers, running a seemingly identical everything, have no such problems; (b) I have been using Chrome to run this code (our company's JavaScript app) for many months and this just started happening for no apparent reason.
I checked out the Apache logs, they appear to be processing the request normally and to completion, but Chrome never sees the reply, apparently.
A couple of other clarifications: prior to the failure, the same Chrome and Apache return a truckload of JS and image files normally, eg., things seem to be fine right up until they aren't. The request is not particularly large (a few hundred bytes in and out) or complex in any obvious way.
If anybody can give me some hints of where to look, I'd be grateful!
I'm experiencing similar behavior with slightly different symptoms. My ajax requests work fine, every second request up to 6 requests, then they all start failing (same url as when working, same payload, etc), but in my case they're not even hitting the server, just stuck in "Pending" in Inspector.
I dont have an answer for you, but to help debug, have you tried chromes net-internals?
Point your browser at:
chrome://net-internals/#sockets
and/or
chrome://net-internals/#events
I see my requests in #sockets go into "active", but never come back, and in #events I can see that the request stalls after the HOST_RESOLVER_IMPL_REQUEST stage.
I'm thinking it could be a resource issue caused by not properly ending the request, but thats just pure speculation.

How can I validate http response headers?

It's the first time I am doing something with headers. I am mainly concerned with Cache-Control but there may be others I will need to check as well. For example, I try to send the following header to the browser (based on tutorials I just read):
Cache-Control:private, max-age=2011-12-30 11:40:56
Google Chrome displays it this way in Network -> Headers -> Response headers, but how do I know if it's correct, that there aren't any typos, syntax errors and such? Will it really work? Will the browser behave like I want it to, or will it treat it like a gibberish (something like "unknown header/value")? I've tried sending nonsensical headers on purpose but they got displayed with the rest. Is there any Chrome tool / addon for that, or any other way? Thank you in advance!
I'm afraid you won't be able to check if the resource has been cached by proxies en route, but you can check if your browser has cached it.
While in the Network panel of Chrome DevTools, hit F5 to reload your page. You should see something like "304 Not Modified" in the status field for the resource you are treating (which means the resource has not been modified and its contents were not received from the server but rather loaded from the browser's cache.)

Any way to get around the browser http timeout during debugging?

I am currently working on a Django development. There is a problem, which isn't a true problem but very annoying. Often, when I try to debug my Django app by putting down some break points, I get this error at the server end:
error: [Errno 32] Broken pipe
After reading this other post, Django + WebKit = Broken pipe, I have learned that this has nothing to do with the server but the client browser used. Basically, what happened is that the browser has a http request timeout. If it doesn't receive a response within the timeout, it will close down the connection with the server.
I find this timeout isn't really needed, indeed causing headache, during debugging. Is there any way I can lift this timeout or increase it for my browser (Chrome)? Or maybe a substitute browser that doesn't have this constraint?
Note: Although I am using Django and have mentioned about it, this isn't a Django-related question. It's more like a question on how to make my debugging process more effective.
I prefer using linux/unix curl command for debugging web applications. It's good approach, especially if you want to focus on some specific request, for example: POST does not work fine for some set of parameters, or cookies are not set as expected.
Of course it may take some time at the beginning to find out how to use it, but then, you will have a total control about every single piece of request: timeouts, cookies, headers and so on. It's very helpful, because you can be sure that what you wanted to send is actually sent (no additional data is added by the web browser).

How does the Firefox website make its download stats page work?

On the Mozilla website, there’s a page showing (apparently) live download statistics for Firefox: http://www.mozilla.com/en-US/firefox/stats/
How are they performing their request to get the live stats data? I can not see a constant connection in Firebug.
How is this working?
Looking at the country_report.json response in the Net tab of firebug, you can see something like this for each country:
{"total":95843579,"rps":[5,6,6,7,4,9,12,9,3,10,6,8,8,7,5,10,8,4,12,8,10,10,7,4,9,13,9,4,9,13,7,7,6,18,10,7,9,5,3,6,5,11,9,5,6,9,7,2,8,9,11,5,10,7,5,6,11,7,7,2],"count":455,"name":"United States","code":"US"}
So those graphs are not being updated every second in real time. Instead, they are plotting a recent history of requests, one point per second, and periodically requesting a new set of data to plot.
It seems they use something called SQLstream on their end to gather that data.
OK, here goes. The question I don't understand is answered here:
http://blog.mozilla.com/webdev/2009/08/18/download-stats-move-to-mozilla-com/
have fun :-)

Django: How to track down a spurious HTTP request?

I have 3 AJAX functions to move data between a Django app on my website and some JavaScript using YUI in the browser. There is not a major difference between them in terms of their structure, concept, code, etc. 2 of them work fine, but in the 3rd one, I get one spurious HTTP request immediately after the intended request. Its POST data contains a subset of the POST data of the intended request. The request meta data is identical except for the CONTENT_LENGTH (obviously) and the CONTENT_TYPE which is 'text/plain; charset=UTF-8' for the intended and 'application/x-www-form-urlencoded' for the unwanted request. I do not set the content type explicitely at all which seems to suggest both requests do not have the same origin and the second one just pops out of thin air.
The intended request sets HTTP_CACHE_CONTROL': 'no-cache' and 'HTTP_PRAGMA': 'no-cache', the spurious one does not. The dev server log output for both requests is
[15/Feb/2010 15:00:12] "POST /settings/ HTTP/1.1" 200 0
What does the last 0 at the end mean ? Could not find any documentation on that. This value is usually non-zero... In Apache, it is the total size in bytes of the server response, can someone confirm it's the same for Django ?
My problem obviously is to find out where this additional request comes from.
I am fairly familiar with JS debugging using Firebug and I think I'm good at Python and Django, but I do not know a lot about the internals of HTTP requests and responses. I can breakpoint and step through the JS code that sends the intended XMLHTTP request, but that breakpoint does not get hit again.
The problem occurs with both FF3 and Safari, I'm on Snow Leopard, so I can't test with IE or Chrome.
I've looked at Django debugging techniques and tools like http://robhudson.github.com/django-debug-toolbar/ but I think I already have the information they can give me.
Can someone advise on a strategy or a tool to narrow the problem down ?
The problematic AJAX function submits form data, the working two don't. Forms have a default action which takes place when the form is submitted: post a request with the form data. I failed to prevent this default action.
So the spurious request did indeed come out of the dark underwood of the browser, there is no code in my js files that sends it.
Solution:
YAHOO.util.Event.preventDefault(event);
at the beginning of the form submit event handler.
See also http://developer.yahoo.com/yui/examples/event/eventsimple.html

Resources