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.
Related
The User-Agent Reduction origin trial is valid from Chrome version 95 to 101 according to the official documentation, but looking at the token acquisition screen, it seems to be valid up to version 111. I am currently on version 109. Is this one excluded?
https://developer.chrome.com/en/blog/user-agent-reduction-origin-trial/
https://developer.chrome.com/origintrials/#/view_trial/-7123568710593282047
Also, this one is intended to test in a situation where the user agent string and javascript api have been completely removed or changed. Is there another way to test before they are completely removed?
We would appreciate it if you could enlighten us.
I have added the necessary settings to the response headers, referring to the official documentation, but it does not work correctly.
https://developer.chrome.com/en/blog/user-agent-reduction-origin-trial/
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
I have created a safari plugin using NPAPI and I want to add a NSView in my plug-in.
When I try to get NPWindow throw function NPP_SetWindow(NPP instance, NPWindow* window), the second parameter is nil.
I think my plug-in is windowless, but i don't know how to create a windowed.
NPAPI on Mac does not support NSView as a windowing mode. There are two supported modes:
CoreAnimation (or InvalidatingCoreAnimation on Chrome and Firefox)
CoreGraphics
There used to be a QuickDraw mode, but that's deprecated.
For more information, see Stuart Morgan's excellent blog post on the subject.
It is possible to make a NSView render to a CoreGraphics context but you'd have to proxy all of the events and it is far from perfect.
EDIT: To further explain the answer to your question, the reason that the window parameter is NULL (it's a C api, not Obj C, so it's NULL, not nil... despite them being the same thing =]) is because in the Cocoa Event Model you get a CGContextRef as part of the draw event which is only valid during the context of that event.
I'm using the latest Google Chrome stable (19.0.1084.56 m) on Windows 7 and experimenting with Mutation observers for the first time. (The project is a user script for a third party website, the server of which I have no access to.)
So it happens that MutationRecord has a field oldValue:
record . oldValue
The return value depends on type. For "attributes", it is the value of the changed attribute before the change. For "characterData", it is the data of the changed node before the change. For "childList", it is null.
So I'm monitoring for changes to the characterData but when I get the MutationRecord the oldValue field is always null.
Should it be working, is there a possibility I've got something wrong, or is this feature just too bleeding edge to expect to work yet?
Is there somewhere I can find Google's documentation, bug report, feature request, etc that might declare whether this is implemented or when it might be?
Configure your observer with:
observer.observe(container, {
attributeOldValue : true
});
Full API documentation:
https://developer.mozilla.org/pt-BR/docs/Web/API/MutationObserver
I came across this code change in Chromium. It says Chromium now supports both handshake versions, which the code seems to confirm. I mean the second version at Wikipedia (draft-ietf-hybi-thewebsocketprotocol-06).
However, when I connect to my server, the only thing I obtain is the old version, i.e. including these headers:
Sec-WebSocket-Key1: 4 #1 46546xW%0l 1 5
Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
but not the new version which would be a request containing:
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
What am I missing here? I downloaded the latest nightly build and it has been included more than two weeks ago, so that cannot be the cause I guess.
How can I make a WebSocket send the new handshake version?
The code link you posted is for the server-side of the handshake (there is a few places this will likely be used in Chrome such as remote debugging and as a proxy for extensions).
If you really want use the new HyBi-07 protocol version you can try using this branch of web-socket-js that I made. Once Chrome switch to the new protocol, web-socket-js will switch by default also. In order to make web-socket-js work in a browser that already has WebSockets support you will need make some minor tweaks to it to use a different object name instead of WebSocket.
I expect Chrome/WebKit will add the new protocol before long. Note that the API changes to add binary support have only recent been decided so Chrome the new protocol may be added before the API fully supports the new functionality enabled by the protocol.
The only browser I know of that implements the 07 protocol is this build of FF4:
http://www.ducksong.com/misc/websockets-builds/ws-07/