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).
Related
This thing just seems to give me problem after problem.
I posted another question earlier, trying to solve the problem of retaining my session state between closing and opening through Watir. Firefox achieves this on its own, so I figured if I just set the preferences correctly, it'd save my state. I ended up having to go into the selenium-webdriver source and make some changes in order to achieve this in reality.
So, I was just testing my application. Part of its behavior is to loop through a bunch of pages and extract text from them. While it's looping, I simply have it in a while true loop, and figured "hey, I can just stop the program with Ctrl+C". Well, this worked fine up to now, until it came to saving the states.
Ctrl+C causes it not to save its state. My guess as to why is that you need to actually close the browser (and I actually recreated the bug in IRB, so I'm pretty sure this is the case). Simple, right? Why not just use an ensure block with #browser.close in it? That was my first thought.
So, when I try it this way, it does hit the ensure block, and the ensure block calls a method called kill. Kill calls #browser.close if #browser.exists?. The problem is that when it tries to execute this line, I get a nice long list of errors leading up to selenium-webdriver. It seems as if it's trying to make an HTTP request as part of its close functionality, and is failing because, perhaps, Ctrl+C exited the application.
The stack trace is located at https://gist.github.com/Inkybro/5557085
The very last thing I thought was that maybe I needed to let any calls to the #browser object complete, so I placed a bunch of trap('INT', 'IGNORE') and trap('INT', 'DEFAULT') lines around these pieces of code. This also doesn't seem to do the trick.
I'm not really sure as to why, which is why I'm posting here. What I think needs to happen is that whatever processing is going on at the time of Ctrl+C needs to finish processing before #browser.close can be called. If anybody has experience with Watir and/or Selenium, or even if you don't, perhaps you could help me out?
Are you supposed to be testing the browser itself, or your product? Because really, if you are doing things like above, (logging in, closing and re-opening the browser to see if you are still logged in) it sounds to me like you are basically testing the browser's ability to store and read cookies and properly provide them when making requests of a page.
What about if you presume for a moment that the browser in fact does what it is supposed to do with regard to cookie management and usage? If you do that, then what becomes important? I think it would be that your app tells the browser to create the proper cookie, with the proper contents.
So maybe rather than actually trying to test that firefox will in fact use it's cookies correctly (or any other browser doing that for that matter) why not simply test that when the user has logged in, that the proper cookies have been created? You may also have to test that the cookie is updated periodically so that a user's session does not expire while they are actively using the site. again pretty easy to test by just looking at the cookies
You might also want to test that your server is sensitive to changes in the cookie, or a missing cookie. That the server is looking at the cookie and is not depending on session variables is also pretty easy to test, login, alter or clear the cookie, try to access a page and see if it fails.
So with that you get three things
1) Proper cookies created upon login.
2) Cookies kept updated as various pages are accessed.
3) Missing or altered cookie == no soup for your user.
(#4 site works properly if cookies present is implied by the three above and all the rest of your tests that exercise your site/app)
Stop trying to do the work of the mozilla test team, and refocus on testing your application.
I'm still not sure what you try to achieve, but this hacky piece of code ensures browser is closed on Ctrl+C and no your exception is raised:
require 'watir-webdriver'
begin
browser = Watir::Browser.new
loop do
# some code
end
rescue SystemExit, Interrupt
puts 'Exiting!'
ensure
begin
browser.close
rescue Errno::ECONNREFUSED
# do nothing
end
end
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.
There are several topics about the problem with cross-domain AJAX. I've been looking at these and the conclusion seems to be this:
Apart from using somthing like JSONP, or a proxy sollution, you should not be able to do a basic jquery $.post() to another domain
My test code looks something like this (running on "http://myTestdomain.tld/path/file.html")
var myData = {datum1 : "datum", datum2: "datum"}
$.post("http://External-Ip:port", myData,function(return){alert(return);});
When I tried this (the reason I started looking), chrome-console told me:
XMLHttpRequest cannot load
http://External-IP:port/page.php. Origin
http://myTestdomain.tld is not allowed
by Access-Control-Allow-Origin.
Now this is, as far as I can tell, expected. I should not be able to do this. The problem is that the POST actually DOES come trough. I've got a simple script running that saves the $_POST to a file, and it is clear the post gets trough. Any real data I return is not delivered to my calling script, which again seems expected because of the Access-control issue. But the fact that the post actually arrived at the server got me confused.
Is it correct that I assume that above code running on "myTestdomain" should not be able to do a simple $.post() to the other domain (External-IP)?
Is it expected that the request would actually arrive at the external-ip's script, even though output is not received? or is this a bug. (I'm using Chrome 11.0.696.60 )
I posted a ticket about this on the WebKit bugtracker earlier, since I thought it was weird behaviour and possibly a security risk.
Since security-related tickets aren't publicly viewable, I'll quote the reply from Justin Schuh here:
This is implemented exactly as required by the spec. For simple cross-origin requests http://www.w3.org/TR/cors/#simple-method> there is no pre-flight check; the request is made and the response cannot be read if the appropriate headers do not authorize the requesting origin. Functionally, this is no different than creating a form and using script to make an off-origin POST (which has always been possible).
So: you're allowed to do the POST since you could have done that anyway by embedding a form and triggering the submit button with javascript, but you can't see the result. Because you wouldn't be able to do that in the form scenario.
A solution would be to add a header to the script running on the target server, e.g.
<?php
header("Access-Control-Allow-Origin: http://your_source_domain");
....
?>
Haven't tested that, but according to the spec, that should work.
Firefox 3.6 seems to handle it differently, by first doing an OPTIONS to see whether or not it can do the actual POST. Firefox 4 does the same thing Chrome does, or at least it did in my quick experiment. More about that is on https://developer.mozilla.org/en/http_access_control
The important thing to note about the JavaScript same-origin policy restriction is that it is something built into modern browsers for security - it is not a limitation of the technology or something enforced by servers.
To answer your question, neither of these are bugs.
Requests are not stopped from reaching the server - this gives the server the option to allow these cross-domain requests by setting the appropriate headers1.
The response is also received back by the browser. Before the use of the access control headers 1, responses to cross-domain requests would be stopped dead in their tracks by a security conscious browser - the browser would receive the response but it would not hand it off to the script. With the access control headers, the server has the option of setting the appropriate headers indicating to a compliant browser that it would like to allow certain origin URLs to make cross domain requests.
The exact behaviour on response might differ between browsers - I can't recall for sure now but I think Chrome calls the success callback function when using jQuery's ajax() but the response is empty. IIRC, Firefox will not invoke the success function.
I get the same thing happening for me. You are able to post across domains but are not able to receive a response. This is what I expected to be able to do and happens for me in Firefox, Chrome, and IE.
One way to kind of get around this caveat is having a local php file with will call the data via curl and respond the response to your javascript. (Kind of restated what you said you knew already.)
Yes, it's correct and you won't be able to do that unless you use any proxy.
No, request won't go to the external IP as soon as there is such limitation.
I'm seeing an odd behavior in WebKit (on Android) where my server process is sending it a response that it needs to handle immediately (rather than wait for readyState 4). In Firefox and Safari this works as expected, but on webkit, not only does it not respond to the readyState but instead it appears to fire off a repeat request to the server!
This only seems to happen when the server takes a little while to react to the request. I'm still poking around to see what the exact circumstances are that bring this about, but am curious if this is a known bug and what, if anything, is a workaround.
[EDIT] This is just getting weirder and weirder. As long as the server responds within about 10 seconds, everything is fine. But if it takes longer than that, then the request is resubmitted. However, the browser appears to not be aware of this re-submission, or if it is, it's not reporting it in any way. I attached a unique ID to the request and when it arrives for the second time on the server the id is the same. But it's definitely spawning off an additional call to the server. I'm sort of at a loss as to how to debug this further.
No one has piped in, so. I have fixed the problem by killing the connection from the server side.
So, my solution:
a) client makes call to server (which is a perl.cgi)
b) server code:
print (some JSON for the broswer);
close(STDOUT); #this sends a readyState 4 to the browser and closes the connection.
&methodThatTakesAWhile();
This doesn't explain WHY the browser is misbehaving, but it does get around this particular bug.
For some reason, while using AJAX (with my dashcode developed application) the browser just stops uploading and returns status codes of 0. Why does this happen?
Another case:
It could be possible to get a status code of 0 if you have sent an AJAX call and a refresh of the browser was triggered before getting the AJAX response. The AJAX call will be cancelled and you will get this status.
In my experience, you'll see a status of 0 when:
doing cross-site scripting (where access is denied)
requesting a URL that is unreachable (typo, DNS issues, etc)
the request is otherwise intercepted (check your ad blocker)
as above, if the request is interrupted (browser navigates away from the page)
Same problem here when using <button onclick="">submit</button>. Then solved by using <input type="button" onclick="">
Status code 0 means the requested url is not reachable. By changing http://something/something to https://something/something worked for me. IE throwns an error saying "permission denied" when the status code is 0, other browsers dont.
It is important to note, that ajax calls can fail even within a session which is defined by a cookie with a certain domain prefixed with www. When you then call your php script e.g. without the www. prefix in the url, the call will fail and viceversa, too.
Because this shows up when you google ajax status 0 I wanted to leave some tip that just took me hours of wasted time... I was using ajax to call a PHP service which happened to be Phil's REST_Controller for Codeigniter (not sure if this has anything to do with it or not) and kept getting status 0, readystate 0 and it was driving me nuts. I was debugging it and noticed when I would echo and return instead of exit the message I'd get a success. Finally I turned debugging off and tried and it worked. Seems the xDebug debugger with PHP was somehow modifying the response. If your using a PHP debugger try turning it off to see if that helps.
I found another case where jquery gives you status code 0 -- if for some reason XMLHttpRequest is not defined, you'll get this error.
Obviously this won't normally happen on the web, but a bug in a nightly firefox build caused this to crop up in an add-on I was writing. :)
This article helped me. I was submitting form via AJAX and forgotten to use return false (after my ajax request) which led to classic form submission but strangely it was not completed.
"Accidental" form submission was exactly the problem I was having. I just removed the FORM tags altogether and that seems to fix the problem. Thank you, everybody!
I had the same problem, and it was related to XSS (cross site scripting) block by the browser. I managed to make it work using a server.
Take a look at: http://www.daniweb.com/web-development/javascript-dhtml-ajax/threads/282972/why-am-i-getting-xmlhttprequest.status0
We had similar problem - status code 0 on jquery ajax call - and it took us whole day to diagnose it. Since no one had mentioned this reason yet, I thought I'll share.
In our case the problem was HTTP server crash. Some bug in PHP was blowing Apache, so on client end it looked like this:
mirek#toccata:~$ telnet our.server.com 80
Trying 180.153.xxx.xxx...
Connected to our.server.com.
Escape character is '^]'.
GET /test.php HTTP/1.0
Host: our.server.com
Connection closed by foreign host.
mirek#toccata:~$
where test.php contained the crashing code.
No data returned from the server (not even headers) => ajax call was aborted with status 0.
In my case, it was caused by running my django server under http://127.0.0.1:8000/ but sending the ajax call to http://localhost:8000/. Even though you would expect them to map to the same address, they don't so make sure you're not sending your requests to localhost.
In our case, the page link was changed from https to http. Even though the users were logged in, they were prevented from loading with AJAX.
In my case, setting url: '' in ajax settings would result in a status code 0 in ie8.. It seems ie just doesn't tolerate such a setting.
For me, the problem was caused by the hosting company (Godaddy) treating POST operations which had substantial response data (anything more than tens of kilobytes) as some sort of security threat. If more than 6 of these occurred in one minute, the host refused to execute the PHP code that responded to the POST request during the next minute. I'm not entirely sure what the host did instead, but I did see, with tcpdump, a TCP reset packet coming as the response to a POST request from the browser. This caused the http status code returned in a jqXHR object to be 0.
Changing the operations from POST to GET fixed the problem. It's not clear why Godaddy impose this limit, but changing the code was easier than changing the host.
I think I know what may cause this error.
In google chrome there is an in-built feature to prevent ddos attacks for google chrome extensions.
When ajax requests continuously return 500+ status errors, it starts to throttle the requests.
Hence it is possible to receive status 0 on following requests.
In an attempt to win the prize for most dumbest reason for the problem described.
Forgetting to call
xmlhttp.send(); //yes, you need this pivotal line!
Yes, I was still getting status returns of zero from the 'open' call.
In my case, I was getting this but only on Safari Mobile. The problem is that I was using the full URL (http://example.com/whatever.php) instead of the relative one (whatever.php). This doesn't make any sense though, it can't be a XSS issue because my site is hosted at http://example.com. I guess Safari looks at the http part and automatically flags it as an insecure request without inspecting the rest of the URL.
In my troubleshooting, I found this AJAX xmlhttpRequest.status == 0 could mean the client call had NOT reached the server yet, but failed due to issue on the client side. If the response was from server, then the status must be either those 1xx/2xx/3xx/4xx/5xx HTTP Response code. Henceforth, the troubleshooting shall focus on the CLIENT issue, and could be internet network connection down or one of those described by #Langdon above.
In my case, I was making a Firefox Add-on and forgot to add the permission for the url/domain I was trying to ajax, hope this saves someone a lot of time.
Observe the browser Console while making the request, if you are seeing "The Same Origin Policy disallows reading the remote resource at http ajax..... reason: cors header ‘access-control-allow-origin’ missing" then you need to add "Access-Control-Allow-Origin" in response header. exa: in java you can set this like response.setHeader("Access-Control-Allow-Origin", "*") where response is HttpServletResponse.