There's no perfect way to change the user agent string for the UWP WebView (x-ms-webview in HTML, Windows.UI.Xaml.Controls.WebView in XAML, and Windows.Web.UI.Interop.WebViewControl in Win32) but there are two imperfect methods folks end up using.
The first is to call UrlMkSetSessionOption. This is an old public API that allows you to configure various arcane options including one that is the default user agent string for requests running through urlmon. This API is allowed by the Microsoft Store for UWP apps. The change it applies is process wide which has two potential drawbacks. If you want to be able to have different UA strings set for different requests from a WebView that's not really possible with this solution. The other drawback is if you're using out of process WebView, you need to ensure you're calling into UrlMkSetSessionOption in the WebView's process. You'll need to write third party WinRT that calls UrlMkSetSessionOption, create the out of proc WebView, navigate it to some trusted local page, use AddWebAllowedObject or provide that URI WinRT access, and call into your third party WinRT. You'll need to do that for any new WebView process you create.
The second less generally applicable solution is to use NavigateWithHttpRequestMessage and set the User-Agent HTTP header. In this case you get to control the scope of the user agent string changes but has the limitations that not all sub resource downloads will use this user agent string and for navigations you don't initiate you have to manually intercept and re-request being careful to transfer over all POST body state and HTTP headers correctly. That last part is not actually possible for iframes.
"Children of Magenta" '97 talk for pilots on how to better use (and not use) flight
automation https://www.youtube.com/watch?v=pN41LvuSz10 …
As the title suggests, spoilers for The Interview follow.
Towards the end of the movie, after Dave Skylark is shot, he miraculously has a bullet proof vest, blows up Kim Jong-un, finds a random tunnel and is picked up by Seal Team Six. These are the same details of the unbelievable scenario that Dave Skylark describes to Agent Lacey at the beginning of the movie.
This isn't a coincidence. Everything after Dave is shot is his fantasizing about how things should have gone as he dies in the interview chair. Unsurprisingly his fantasy closely matches his original ridiculous thoughts about how he would assassinate and escape.
This is similar to movies like Brazil in which the later fourth of the movie is the main character’s romantic fantasy as he is tortured and killed in real life. Or Total Recall where the end of the movie matches the description of the memories that the main character will have implanted at the beginning.
Its safe to assume that after Dave is killed, Aaron and Sook are captured and also killed.
In IE10 and other new browsers one may create MessageChannel objects that have two MessagePorts each connected (w3c spec calls it entangled) to one another such that postMessage on one port results in the message event firing on the other. You can pass an array of ports as the last parameter to postMessage and they show up in the ports property of the message event arg.
The postMessage here is like the worker postMessage and unlike the window and iframe postMessage in that it applies no origin checking:
Unfortunately the origin isn't an optional parameter at the end to make the two postMessages have the same signature.
On the event handler side, the event arg always has an origin property. But in the no origin case it is always the empty string.
There is also a source property on the message event arg which if set is an object that has a postMessage property allowing you to post back to your caller. It is set for the origin case, however, in the no origin case this property is null. This is somewhat reasonable because in the case of MessagePort and Workers there are only two endpoints so you always know the source of a message implicitly. Unlike the origin case in which any iframe or window can be calling postMessage on any other iframe or window and the caller is unknown. So not unreasonable but it would be nice if the source property was always set for consistency.
When a MessageChannel is created it has two MessagePorts, but until those ports are started they will queue up any messages they receive. Once started they will dispatch all queued messages. Ports don't have to be started to send messages.
A port may be started in two ways, either by explicitly calling the start method on the port, or by setting the onmessage callback property on the port. However, adding an event listener via addEventListener("message", does not start the port. It works this way in IE and Chrome and the spec states this as well.
The justification is that since you can have only one callback via onmessage that once set you must implicitly be ready to receive messages and its fine to start the port. As opposed to the addEventListener in which case the user agent cannot start implicitly because it doesn't know how many event listeners will be added. I found Hixie stating this justification in geoloc meeting notes.
A great JS API to add Clippy or other agents to your website! Make them talk, dance, gesture, etc
IETF draft on the contents of the User Agent HTTP header.
From the document: ‘Appendix B. Implementation Report: The encoding defined in this document currently is used for two different HTTP header fields: “Content-Disposition”, defined in [RFC6266], and “Link”, defined in [RFC5988]. As the encoding is a profile/clarification of the one defined in [RFC2231] in 1997, many user agents already supported it for use in “Content-Disposition” when [RFC5987] got published.
Since the publication of [RFC5987], two more popular desktop user agents have added support for this encoding; see http://purl.org/
NET/http/content-disposition-tests#encoding-2231-char for details. At this time, only one major
desktop user agent (Safari) does not support it.
Note that the implementation in Internet Explorer 9 does not support the ISO-8859-1 encoding; this document revision acknowledges that UTF-8 is sufficient for expressing all code points, and removes the requirement to support ISO-8859-1.’
Yay for UTF-8!
Shortly after joining the Internet Explorer team I got a bug from a PM on a popular Microsoft web server product that I'll leave unnamed (from now on UWS). The bug said that IE was handling empty path segments incorrectly by not removing them before resolving dotted path segments. For example UWS would do the following:
A.1. http://example.com/a/b//../
A.2. http://example.com/a/b/../
A.3. http://example.com/a/B.1. http://example.com/a/b//../
B.2. http://example.com/a/b/The URI RFC allows path segments of zero length and does not assign them any special meaning. So generic user agents that intend to work on the web must not treat an empty path segment any different from a path segment with some text in it. In the case above IE is doing the correct thing.
That's the case for generic user agents, however servers may decide that a URI with an empty path segment returns the same resource as a the same URI without that empty path segment. Essentially they can decide to ignore empty path segments. Both IIS and Apache work this way and thus return the same resource for the following URIs:
http://exmaple.com/foo//bar///baz
http://example.com/foo/bar/baz
Netflix lets you watch a subset of their movies online via their website and a subset of those movies are available to watch on the Xbox 360's Netflix app. so its not always easy to find movies to watch on Xbox 360. Yet, I regularly see my Xbox friends using the Netflix app and its a shame they didn't make an easy way to share movie recommendations with your friends. Instead we must share movie recommendations the old fashioned way. Here's the movies I've found and enjoyed on my 360.
Some rights reserved