I'm using fetch in my application for requests and the polyfill for browsers that don't support it. I've never had problems until now (the app works on Edge 13, IE, etc).
More specifically, on Microsoft Edge 14 self.fetch exists so the polyfill doesn't apply. If I call fetch with one parameter such as fetch('/api/users') it works, but calling it with 2 parameters (I need to set some headers, the method, etc)
fetch(request.url, {
headers,
method: request.method || 'GET',
body: request.body || null
})
it doesn't work. It doesn't even make the call, doesn't throw an error, nothing. I've been googling for an hour and so far no luck. Any ideas?
The obvious would be to do a dirty check of the useragent and override the native function with the polyfill, but I'd like something more "elegant". Maybe I'm doing something wrong. Thanks!
Okay, so I found an answer with the help of this post. Apparently it was crashing when trying to send a body parameter on a GET request even if it was empty or undefined.
So I'm just making a check first for the method, and if it's a GET I'm not adding the body anymore. This fixed my problem
Anyone else who gets stuck with this:
Check your version of Edge, 17 doesn't support Promises, upgrade Windows with the October 2018 update which includes Edge 18 and Promises are supported, fetch requests will work.
https://www.microsoft.com/ja-jp/software-download/windows10
Related
Ok, here is a strange one.
For testing this issue I have a endpoint like this:
[HttpPut]
public string Put(object value)
{
return value != null ? "ok" : "fail";
}
When throwing data directly at it the value object allways becomes the JSON i throw at it (as expected). However the app I'm developing requires me to go through a gateway that adds security to the call by verifying some headers and so.
When going through the gateway that forwards to my endpoint everything also seems ok until the body of the call hits a certain size(apperantly 471 chars is ok 472 is not) then the value object is null (and the therefore the method returns 'fail').
All this led me to believe that the GW truncates the body at a certain size and therefore makes it invalid JSON and the value object becomes null. BUT after talking to the provider of the gateway they told me that they tested it and this could not be the issue.
Here comes the really strange part
In my further pursuit of the problem I added a BeginRequest listener like this:
context.BeginRequest += Application_BeginRequest;
I added only one line to the interceptor for debugging purposes (to see if the body got truncated):
HttpContext.Current.Request.SaveAs("c:\\test.txt", true);
After adding this line everything works like a charm, all call gets thru (regardless of size) and value is never null. I tried removing the line again and we are back to the original issue where it fails at a certain size.
What on earth is going on
I really need some advice here on how to proceed debugging this issue.
Turned out to be an issue in the 3rd party GW anyways. The are now trying to fix the problem.
I am communicating with a third party service via XHR (cannot use ajax as I need to send as ArrayBuffer). I had a bunch of problems getting this to work under WP8 but have finally gotten a connection (always worked fine under android and iOS (phonegap)). The problem I have is that I need to send through a couple of specific headers for authentication. I am sending this through as:
xhr.open("POST", url, true);
xhr.timeout = 30000;
xhr.setRequestHeader("Content-Type",contentType+"; boundary=" + boundary);
xhr.setRequestHeader("Accept","application/json; charset=utf-8");
xhr.setRequestHeader("Authorization",auth);
xhr.setRequestHeader("Date",todayString);
xhr.send(bodyBuf);
In essence this works fine other than: the 'Date' header is never received. I constantly get back a response of 'Date header required'. I know that the actual connection is not something that you will be able to advise on, however I am wondering if anyone has encountered this before? Is everyone else able to set the xhr 'Date' header in WP8 which would imply that something is different in my code/setup or if anyone has any ideas.
btw, I am getting the same result when testing through the emulator and via an HTC it is not specific to a single device. but to the WP8 platform
Thanks,
Have found that this is a known problem. the ie httpwebrequest does not contain a 'Date' header so this can never be set. In order to do this, I have had to make a WP plugin to use the recently added mobile-httpclient code, which can set the 'Date' header.
i've already a working proxy.pac file. I'd like the clients to use different proxyserver depending on their web browser.
No problem I thought. There are many java script snippets out there, to detect browser name/version.
The samples I found uses all "navigator.appName". That works fine if I test this on a regular website. When I put the same into my proxy.pac, it doesn't work. The navigator object doesnt seem to exist.
Has anyone out there a suggestion how to switch the proxy according to the user agent?
My goal is, that all IE6 uses a specific proxy, where the rest just use the default proxy.
Background: IE6 does not support Kerberos authentication, which is used on the default proxy. Therefore I setup an additional proxy with LDAP authtentication.
Thanks in advance for any help.
Maybe there are some less or more subtle javascript engine differences between the browsers that one can spot, using for example
if (typeof(someIESpecificFunction) != "undefined")
or using try and catch
or comparing results of some builtin functions for subtle differences
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(ECMAScript) and http://www.robertnyman.com/javascript/index.html may be helpful for a start?
Update: one more browser-version specific behaviour:
from http://technet.microsoft.com/en-us/library/dd361918.aspx:
function FindProxyForURL(url, host)
{
if(weekdayRange("WED", "SAT", "GMT"))
return "PROXY proxy:80";
else
return "DIRECT";
}
The weekdayRange( <day1> [,<day2>] [,<GMT>] ) function returns whether the current system time falls within the range specified by the parameters <day1>, <day2>, and <GMT>. Only the first parameter is necessary. The GMT parameter sets the times to be taken in GMT rather than in the local time zone.
Note Where the function is called with <day1> == <day2>, previous versions of Internet Explorer would yield results different from results with Netscape Navigator. Specifically, previous versions of Internet Explorer would interpret this day range as an entire week, while Internet Explorer 6 and Netscape Navigator interpret the range as a single day. For example, if the current day is Monday, the call weekdayRange("TUE", "TUE") returns TRUE on previous versions of Internet Explorer and FALSE on Internet Explorer 6 and Netscape Navigator.
Update 2: According to http://blogs.msdn.com/b/wndp/archive/2006/07/18/ipv6-wpad-for-winhttp-and-wininet.aspx one should be able to distinguish also IE7 from older IE versions (other browsers may and may not support these extensions, like for example mentioned here about Chrome: http://code.google.com/p/pactester/issues/detail?id=9)
Based on the information so far it should be possible to distinguish IE 5.5, IE 6, IE 7, IE 8, IE 9?
Please let us know if You find anything like that useful.
You may try detecting IE inside PAC script via Conditional Compilation: const ifIE = /*#cc_on!#*/false;.
Conditional Compilation may vary depending on new or old IE/Edge versions.
I haven't done any testing of this answer --, please, let us know if it works in comments.
I am using HTTPService for authentication in my appliaction and I am parsing the messahe body of faultEvent of fault handler to determine what fault is coming. Every thing is working fine in IE but in case of Chrome and Mozilla the message body of FaultEvent of faulthandler is coming empty.
Please suggest how can I handle faults in Mozilla and Chrome ?
Had similar problem and found that flash gets from server only 'HTTP 200' responses. All faults are handled as faults without any messages forwarded. So, we 'invented' our own web-services, that add additional header. We always return status 200 for HTTP response, but add return code and message into our header.
Then we parse our custom header and have true response.
Also have read, that this problem is solved in newest flash player 10, but maybe still in development versions. And because we need to support also version 9, we keep using our custom headers.
I've downloaded the examples for both the Request and Request.HTML and cannot make either work. I unzipped them to a folder and browsed to their index.html to execute them as is, but the response is always "The request failed." with no clues as to why.
I've played around with them with different permutations and can get the request to complete but it always fails. Is there any way to get a reason for failure? I've tried three different browsers turned off my firewall, used relative and absolute file references but nothing works. Am I missing something glarringly obvious? I'd post the code, but it is the examples exactly as is...
Any help would be awesome.
Cheers,
Justin.
If I'm remembering correctly, AJAX requests in most browsers cannot be done via the local file system - you'll need an actual web server like Apache going. In Windows, XAMPP will get you up and running with Apache in minutes.
Most any webserver should work. It's just that your filesystem doesn't "respond" to browser requests the way a web server does:
ajax requests that are executed
locally (against the file system)
don't work well because the ajax logic
is looking for a state change and a
server response, neither of which are
provided by your file system
-- http://forum.mootools.net/viewtopic.php?id=5009
The XMLHttpRequest object can handle more than just HTTP requests supposedly, but at least in mootools, it's not meant to. And "file:///..." is not an HTTP request. It's just taking a file from your file system and displaying it in the browser.
So the good news is: any web browser, including even a bare-bones one running on your local machine, should work fine :)
Brilliant!! Thanks very much! I uploaded it to my nearest webserver and sure enough it works.
I did try doing some Ajax calls directly from my filesystem without any javascript libraries - using XMLHttpRequest() - and it worked fine, so this does seem like a strange limitation. Can I be sure this will always work from any webserver, however basic? It's just that this project I'm working on is going to be using multiple hosting environments, mainly just plain HTML type sites for the client enviornments of which I'll have no control... Is there a minimum specification?
Cheers ;)
The XMLHttpRequest() succeeds cause there's nothing wrong with making the local call. it's just different and the problem is in the buggy mootools isSuccess function.
You gotta override it the Request options. Here's how jquery does it
// Determines if an XMLHttpRequest was successful or not
httpSuccess: function( xhr ) {
try {
// IE error sometimes returns 1223 when it should be 204 so treat it as success, see #1450
return !xhr.status && location.protocol === "file:" ||
// Opera returns 0 when status is 304
( xhr.status >= 200 && xhr.status < 300 ) ||
xhr.status === 304 || xhr.status === 1223 || xhr.status === 0;
} catch(e) {}
return false;
},