I've been looking into an issue i'm experiencing when posting to a server, specifically when opening a Word file from the returned response.
An XMLHttpRequest object via JavaScript is being used to send data back to the clients machine from the web server using the .open and .send functions - the responseText having the resultant XML within.
After looking in Fiddler this request shows the following:
However you can see there's the red symbol, looking at the Fiddler documentation this means that the "Session was aborted by the client, Fiddler, or the Server.".
Furthermore the header for the response appears to be correct:
What would cause the aforementioned behaviour? The browser is not displaying any visible script errors (IE8) and i've made sure that JavaScript errors are not supressed. Looking at the TextView filter in Fiddler you can see the Word data, mentions of Fonts and styles etc.
Thanks for your time!
It appears the issue was due to a mis-registered MXSML .DLL, after re-registering the DLL in question functionality was restored.
Related
This is not a duplicate of questions such as this, but rather the opposite: I have a form that I'm submitting via jQuery
$('<form>', {
action : 'service',
method : 'post',
target : '_blank'
}).append(
$('<input>', {
type : 'hidden',
name : 'payload',
value : JSON.stringify(payload)
})
).appendTo('body').submit().remove();
This is done so that I can open a different page with HTML.
Since I need to submit quite a lot of complex information, what I actually do is serialize them all into a big JSON string, then create a form with only one field ("payload") and submit that.
The receiving end has a filter that goes like this:
if the method is POST,
and there is only one submitted variable,
and the name of that one variable is "payload",
then JSON-decode its value and use it to create fake GET data.
So when the GET data grows too much I can switch methods without modifying the actual script, which notices no changes at all.
It always worked until today.
What should happen
The server should receive a single POST submission, and open the appropriate response in a popup window.
What actually happens instead
The server does receive the correct POST submission...
...apparently ignores it...
...and immediately after that, the browser issues a GET with no parameters, and it is the result of that parameterless GET that gets (pardon the pun) displayed in the popup window.
Quite unsurprisingly, this is always a "You did not submit any parameters" error. Duh.
What I already did
verified that this method works, and has always worked for the last couple of years with different forms and different service endpoints
tried replacing the form with a hardcoded <FORM> in HTML, without any jQuery whatsoever. Same results. So, this is not a jQuery problem.
tried with different browsers (it would not have helped if it only worked on some browsers: I need to support most modern browsers. However, I checked. Luckily, this failure reproduces in all of them, even on iPhones).
tried sending few data (just "{ test: 0 }").
tried halting the endpoint script as soon as it receives anything.
checked Stack Overflow. I found what seems to be the same problem, in various flavours, but it's of little comfort. This one has an interesting gotcha but no, it does not help.
checked firewalls, proxies, adblockers and plugins (I'm now using plain vanilla Firefox).
called the IT guys and asked pointed questions about recent SVN commits. There were none.
What I did not yet do
Check the HTTPS conversation at low level (I don't have sufficient access).
Compared the configuration, step by step, of a server where this works and the new server where it does not.
Quite clearly, put my thinking hat on. There must be something obvious that I'm missing and I'm setting myself up for a sizeable facepalm.
Use a tool like hurl.it or Postman to manually send a request to the server. The tools will nicely display the response from the server including all HTTP headers. I suspect the server responds with a redirect (Status code 30X) which leads to a GET request being issued after the POST completes.
Update: HTTP redirects
HTTP redirects do not necessarily use the same HTTP method or even the same data to issue a request to the redirect target. Especially for non-idempotent requests this could be a security issue (you don't generally want your form submission to be automatically re-submitted to another address). However, HTTP gives you both options:
[...] For this reason, HTTP/1.1 (RFC 2616) added the new status codes 303 and 307 [...], with 303 mandating the change of request type to GET, and 307 preserving the request type as originally sent. Despite the greater clarity provided by this disambiguation, the 302 code is still employed in web frameworks to preserve compatibility with browsers that do not implement the HTTP/1.1 specification.
[from Wikipedia: HTTP 302]
Also for 301s:
If the 301 status code is received in response to a request of any type other than GET or HEAD, the client must ask the user before redirecting.
[from Wikipedia: HTTP 301]
Is it possible to make an http request that has been sent to a server by the browser fail without having to alter the javascript?
I have a POST request that my website is sending to the server and we are trying to test how our code reacts when the request fails (e.g. an HTTP 500 response). Unfortunately, the environment that I need to test it in has uglified and compressed javascript, so inserting a breakpoint or altering the javascript isn't an option. Is there a way for us to utilize any browser to simulate a failed request?
The request takes a long time to complete, so using the browser's console to run a javascript command is a possibility.
I have tried using window.stop(), however, this does not work since I need to failure code to execute.
I am aware of the option of setting up a proxy server, but would like to avoid this is possible.
In Chrome (just checked v63), you can actually block a specific URL (or even a whole domain) from the Network tab. You only need to right-click on the entry and select Block request URL (or Block request domain.)
One possible solution is to modify the XMLHttpRequest objects that will be used by the browser. Running this code in a javascript console will cause all future AJAX calls on the page to be redirected to a different URL (which will probably give a 404 error):
XMLHttpRequest.prototype._old_open =
XMLHttpRequest.prototype._old_open || XMLHttpRequest.prototype.open;
XMLHttpRequest.prototype.open = function(method, url, async, user, pass) {
return XMLHttpRequest.prototype._old_open.call(
this, method, 'TEST-'+url, async, user, pass);
};
Don't overlook the simplest solution: disconnect your computer from the Internet, and then trigger the AJAX call.
Chrome's dev tools have an option to "beautify" (i.e. re-indent) minified JavaScript (press the "{}" button at the bottom left). This can be combined with the "XHR breakpoint" option to break when the request is made. XHR breakpoints don't support modifying the response though AFAIK, but you should be able to find a way to do it via code.
To block a specific URL and make an API call failure, you just need to follow below steps:
Go to Network tab in your browser.
Find that API call which needs to fail(as per your requirement).
Right click on that API call and
Click on 'Block Request URL', you can unblock as well in same manner as the option will turn into 'Unblock'
Just type at the brower a changed URL, e.g. the well formed URL e.g. http://thedomain.com/welcome/ by another placing "XX": http://thedomain.com/welcomeXX/ , that will cause a 404 error (not found)
I faced few problems while using Chrome dev tool. Just want to know whether it's possible and if yes - how. Suggest I have a really massive client side, with hundred of responses per page.
How to find endpoint which handle the response? I mean the first place in js code where the response come in.
How to find the response by it content? For instance, I want to know in which response I've got 45902309509902 value from the table.
How to find endpoint which handle the response?
On the Network tab, you can see where the request was originated, it's the column labelled "Initiator:"
That has a link that will show you the code originating the ajax call (I assume by "response" you're talking about an ajax response). From there, you should be able to find the callback that request is associated with. A lot of times, if you use a library like jQuery, you'll be shown the jQuery code doing the request rather than yours. You can still find what you need, though, by using the un-minified version of the libray, setting a breakpoint on that code (perhaps even a conditional one on, say, the URL being requested), and then when the breakpoint is hit using the call stack to find out where in your code the call actually originates.
How to find the response by it content?
This will be slightly more difficult. Again in the Network tab, you can click each ajax request and see (and search through) the text of there response under the Response sub-tab.
Where do I start debugging a jQuery/Javascript function, that calls an API on my server, when it works perfectly well locally - but when uploaded to the server, just returns an HTTP500 error?
I've tried fiddler, but it shows nothing in JSON/XML - the only thing it does show is in the Auth section:
The server Event Logs show nothing around the times I'm trying to test this.
Does the Fiddler response suggest anything is wrong, or can anyone sugget what I may need to turn on in the Event Viewer to capture whatever these 500 errors may be?
Thanks for any help,
Mark
Try adding some console.log() messages which surround the javascript call and are within the callback functions. Doing so will let you know where the failure is occurring. When debugging javascript I typically stick to the Network tab within Chrome Developer Tools and Firebug. By using these tools you get proper output from your console.log() messages.
Specifically, in your jquery result handler I would add the following:
console.log(resultObject);
This will output the entire object tree so that you can drill down into the meat from within Firebug or Chrome Developer Tools... if you need to.
If, for whatever reason, you are opposed to littering your code with log messages then check to see that the call is actually happening when you are testing from your server. You should see whether or not javascript is sending the HTTP request by looking at your network traffic either in Fiddler or browser based tools. If the request is not happening then your code is breaking prior to the call which, in your case, probably means environmental differences.
Is everything referenced and configured properly? Check for null values due to improper configuration or bad references.
500 is a "server error", which basically means something (could be almost anything) broke at the server side.
I would recommend:
Investigate your options for exception handling: http://www.asp.net/web-api/overview/web-api-routing-and-actions/exception-handling
Consider setting the IncludeErrorDetailPolicy to Always, though note that this is a setting that shouldn't be left in-use on a production environment - Error messages returned from Web API method are omitted in non-dev environment
Examine server-side error logging. I'm a big fan of ELMAH. You'll need a little extra effort to get it working properly in Web API - http://blogs.msdn.com/b/webdev/archive/2012/11/16/capturing-unhandled-exceptions-in-asp-net-web-api-s-with-elmah.aspx
I'm using jQuery's ajax methods to interact with the Twitter REST API.
Their API is a bit annoying, in that some actions will return a 401 HTTP status code. In that case, I just want it to fail, instead of displaying a login box.
I've tried just providing an incorrect user:pass pair in the URL, in case that might suppress the dialog and just get me an error response, but that failed to help.
This question asked exactly the same question, but the answer instead worked out how to not trigger the 401 in the first place.
(In particular this is annoying because it's a bug on their part that's requesting authentication -- the users/show method isn't supposed to be asking for it in the first place.)
Look into suppress_response_codes
It is explained about 1/4 way down the page here:
https://dev.twitter.com/docs/things-every-developer-should-know
From the Twitter documentation (incase it is moved again):
suppress_response_codes: If this
parameter is present, all responses
will be returned with a 200 OK status
code - even errors. This parameter
exists to accommodate Flash and
JavaScript applications running in
browsers that intercept all non-200
responses. If used, it's then the job
of the client to determine error
states by parsing the response body.
Use with caution, as those error
messages may change.