Oct 23, 9:32
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.
2012 Jan 27, 7:29
IETF draft on the contents of the User Agent HTTP header.
2011 Jun 21, 1:22
"This document defines the concept of an "origin", which is often used
as the scope of authority or privilege by user agents. Typically,
user agents isolate content retrieved from different origins to
prevent malicious web site operators from interfering with the
operation of benign web sites. In addition to outlining the
principles that underly the origin concept, this document defines how
to determine the origin of a URI, how to serialize an origin into a
string, and an HTTP header, named "Origin", that indicates which
origins are associated with an HTTP request."
2010 Apr 21, 6:49
"OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize
third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections."
2008 Oct 1, 1:08
A weekly summary of the going-ons in the WHATWG usually on the topic of squabbles in HTML5 esp. what to do about the alt attribute in the img tag. Interesting stuff on charsets.
2008 Sep 8, 7:00
A brief history of user agent strings in web browsers, culminating in: "And thus Chrome used WebKit, and pretended to be Safari, and WebKit pretended to be KHTML, and KHTML pretended to be Gecko, and
all browsers pretended to be Mozilla, and Chrome called itself Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13, and the user
agent string was a complete mess, and near useless, and everyone pretended to be everyone else, and confusion abounded."
2007 Jul 4, 10:58Hackdiary
I really enjoy reading Matt Biddulph's blog hackdiary
. An entry some time ago talked about his Second
Life flickr screen
which is a screen in Second Life that displays images from flickr.com based on viewers suggested tags. I'm a novice to the Second Life scripting API and so it was from this
blog post I became aware of the llHTTPRequest
. This is like the XMLHttpRequest for Second Life code in that it lets you make HTTP requests.
I decided that I too could do something cool with this.
I decided to make a translator object that a Second Life user would wear that would translate anything said near them. The details aren't too surprising: The translator object keeps an owner
modifiable list of translation instructions each consisting of who to listen to, the language they speak, who to tell the translation to, and into what language to translate. When the translator
hears someone, it runs through its list of translation instructions and when it finds a match for the speaker uses the llHTTPRequest to send off what was said to Google translate
. When the result comes back the translator simply says the response.
Unfortunately, the llHTTPRequest limits the response size to 2K and no translation site I can find has the translated text in the first 2K. There's a flag HTTP_BODY_MAXLENGTH provided but it defaults
to 2K and you can't change its value. So I decided to setup a PHP script on my site to act as a translating proxy and parse the translated text out of the HTML response from Google translate. Through
experimentation I found that their site can take parameters text and langpair queries in the query like so:
. On the topic of non US-ASCII characters (which is important for a translator) I
found that llHTTPRequest encodes non US-ASCII characters as percent-encoded UTF-8 when constructing the request URI. However, when Google translate takes parameters off the URI it only seems to
interpret it as percent-encoded UTF-8 when the user-agent is IE's. So after changing my PHP script to use IE7's user-agent
US-ASCII character input worked.
Actually using it in practice is rather difficult. Between typos, slang, abbreviations, and the current state of the free online translators its very difficult to carry on a conversation.
Additionally, I don't really like talking to random people on Second Life anyway. So... not too useful.
2006 Apr 4, 5:30
Conditional Comments and the Version Vector may be used to identify the browser version displaying an html page.
2006 Feb 22, 2:28