Earlier quoted context omitted.
There's a whole class of old ASP sites that break if you take "like Gecko" out of the UA. It would be funny if it hadn't made me cry so often.
Why not just break them?
[deleted]
Why Parse the User Agent?
51–60 of 78 posts
Re: Why Parse the User Agent?
#52I'm working on a single page application that heavily utilizes IndexedDB. While feature detection can tell the presence of it, it tells nothing about the quality of the implementation. For example, in Safari, inserting ~9k rows takes 10 minutes, and IE doesn't support compound key path.
While it's possible to write custom logic to detect the latter, it's impossible to detect the former cheaply and reliably. I guess I have to resort to UA sniffing.
Re: Why Parse the User Agent?
#53The author dismisses feature detection as being "slow", but it's much less error prone: http://www.stucox.com/blog/using-webp-with-modernizr/ You can just cache the result in localStorage; you take a few-millisecond hit once. Here's how the feature detection is done: https://github.com/Modernizr/Modernizr/blob/924c7611c170ef2d... HOWEVER , in this case (webp), it's likely better to detect it on the server: https://gi…
Oh when you are trying to work around different bugs in browsers that claim to implement some features - i.e all the fucking time if you are doing interesting things client side.
Re: Why Parse the User Agent?
#54I do find it slightly strange that saving a few bytes from the size of an image is suddenly of such pressing importance that we need to resort to all these hacks. JPEG2000 has been available in some browsers for years and years now, but I've yet to see any site selectively sending it to supporting browsers to save bandwidth, or anybody advocating for doing that. JPEG2000 first became available in browsers 10+ years a…
[deleted]
Re: Why Parse the User Agent?
#55The whole thing isn't worth as much as it as it seems.
In this case PageSpeed generated JPEG at significantly higher quality than WebP, so most of the file size difference is due to quality difference, not codec compression efficiency (distortion measured with DSSIM for JPEG is .009 and for WebP is .015)
If you make the comparison fair by creating JPEG (using mozjpeg) at the same quality as WebP it's 22539 vs 20158 bytes (11% saving).
Re: Why Parse the User Agent?
#56Earlier quoted context omitted.
Why not just break them?
Because then people use a competing browser that doesn't break the sites they use.
Seriously doubt it. Backwards-incompatible changes (mostly, deprecating some old kludges) had happened many times and I don't think there were any severe migrations.
I'm really not sure cons of User-Agent cleanup (or complete deprecation) outweigh the pros. At the very least I think it's not obvious and is debatable.
Re: Why Parse the User Agent?
#57Earlier quoted context omitted.
Because then people use a competing browser that doesn't break the sites they use.
Seriously doubt it. Backwards-incompatible changes (mostly, deprecating some old kludges) had happened many times and I don't think there were any severe migrations. I'm really not sure cons of User-Agent cleanup (or complete deprecation) outweigh the pros. At the very least I think it's not obvious and is debatable.
What are the pros? Smaller requests are only going to have a very small effect on speed or bytes used.
Re: Why Parse the User Agent?
#58I imagine that in the future with HTTP2 we could send the list of available browser features as HTTP headers such as Animated-WebP: Supported ? With HTTP1 the cost of sending long list of available features would be too big probably. But could HTTP2 solve this problem. If I recall correctly it only sends diffs of headers between subsequent requests in the same connection. Maybe that could be helpful for a class of pr…
I don't think this is a viable solution because vendors are going to get the list wrong. Mobile browsers are a complete mess. Do you think that Apple would have sent a "File upload: Unsupported" flag when they temporarily broke file uploads in iOS 8.0?
Re: Why Parse the User Agent?
#59Earlier quoted context omitted.
From the article: "To emit html that references either a JPEG or a WebP depending on the browser, you need some way that the server can tell whether the browser supports WebP. Because this feature is so valuable, there is a standard way of indicating support for it: include image/webp in the Accept header. Unfortunately this doesn't quite work in practice. For example, Chrome v36 on iOS broke support for WebP images…
That's a good argument for the image host to sniff the UA string in the course of content negotiation. It's not a good argument for crafting html that bypasses content negotiation.
The problem with solving this in content negotiation is that breaks proxy caches. If you serve uncachable html that references either jpg or webp then you can serve those resources as "Cache-Control: public", and if you include a content hash or versioning in the URL then you can send a long cache lifetime. If you use the Accept or User-Agent headers to choose what image format to send them you need to issue a Vary header, and basically all proxy caches will treat that as uncachable.
There's some progress with "Vary: Accept" support, but "Vary: User-Agent" is probably never going to be supported.
Re: Why Parse the User Agent?
#60The fact that UA is so easily spoofed makes it a really poor choice. Client side JS for feature detection can work well, I have a simple example in the code of http://http-echo.com
In practice webp isn't usually spoofed, and when it is it's by people who've thought through the consequences and are in a position to deal with potential breakages.
Client side feature detection can also be spoofed, but in practice that's bit a problem either.