Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Parse the User Agent?

jefftk.com

Post reply on HN
Print view View original

31–40 of 78 posts

Re: Why Parse the User Agent?

#31

Post by ploxiln »

calineczka wrote: post #7

I 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…

The linked page mentions the Accept header, and notes that some popular browsers got it wrong at some point (maybe still?) so now no one can use it anymore. You propose something more specific, but not very different. It'll fall to the same fate eventually, but might give us a couple of years...

Re: Why Parse the User Agent?

#32

Post by jameshart »

cdmckay wrote: post #13
discreditable wrote: post #8

Author is going about this in completely the wrong way. The best way to determine if you should deliver webp or jpeg is to look at the browser's accept header [1]. In this header you will find a listing of what the browser is willing to accept and the order of preference. [1] https://www.igvita.com/2013/05/01/deploying-webp-via-accept-...

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 argument's pretty weak. A bug in chrome v36 on iOS, and a limitation on the forms of webp you can serve if you want them to work in Opera, are not really good enough for me to dismiss the value of Accept headers. Why are you bothered whether the browser might or might not accept animated WebP? You're trying to send a static picture of a kitten. And likewise, Opera's lack of support for lossless? Not relevant to your use case.

Re: Why Parse the User Agent?

#34

Post by IvyMike »

I always wonder why the first browser to misidentify itself as something else wasn't sued.

I mean, I sure couldn't slap a "Internet Explorer" or "Netscape Navigator" splash screen on my shareware, but that's what they're doing in the User-Agent field.

Re: Why Parse the User Agent?

#35

Post by marvy »

IvyMike wrote: post #34

I always wonder why the first browser to misidentify itself as something else wasn't sued. I mean, I sure couldn't slap a "Internet Explorer" or "Netscape Navigator" splash screen on my shareware, but that's what they're doing in the User-Agent field.

Lying to people is not allowed, because you're tricking them into paying you based on false data. Lying to programs is allowed, because you're tricking them into working properly when they would otherwise fail. The first browser to do this had the same motivation as modern browsers do.

Re: Why Parse the User Agent?

#36

Post by Animats »

One of my systems uses the user agent "Sitetruth.com site rating system". This breaks some Coyote Point load balancers. Their parsing of HTTP headers breaks if the last letter of the header is "m". I had to stick an unnecessary "Accept /" header at the end to bypass that.

I suspect that one of their regular expressions has "\m" where they meant "\n".

Re: Why Parse the User Agent?

#37

Post by mitchty »

jimktrains2 wrote: post #12
drivingmenuts wrote: post #9

Yay! Yet another image format that I can't open in Preview, if I save it to my hard drive. Webp may be great for displaying in a web page, but it's TFU if I save it to my hard drive and try to view it with default viewing or editing software. It may not be a proprietary format, but it might as well be.

What image formats are you hitting that Preview (I'm guessing you're on a Mac?) won't open? BTW: gthumb opens it A-OK. So, maybe the issue isn't the openness of the format, but the openness of your platform?

Openness of your platform? God could we get any more passive aggressive with this open source bullshit? Honestly this kind of crap is like doing grade school all over again. Grow up already, does windows support webm/webp natively? Nope, needs plugins.

Webp is in a lot of the same boat as webm legally. It may be "open", whatever the fuck that means anymore, but that doesn't make it patent free or not needing of any licensing concerns. VP8/9/etc... aren't some public domain web format. Even webm infringed on H264 patents as of 2013. Do you really think that is an encouraging thing for lawyers of companies with legal liability to want to risk?

Re: Why Parse the User Agent?

#38

Post by sitharus »

jimktrains2 wrote: post #16

Isn't the problem more that the browser can't be given multiple sources and types and allow it to chose what it believes is best? User-Agent sniffing really does need to die. Part of me wonders what use UA headers serve beyond sniffing and analytics. EDIT: or the Accept (and content-type) header, but that's a next to worthless header anymore :-\

That's actually a solved problem! As the article mentioned, it works the other way around - the browser specifies what it can receive. Since this wasn't around from day 1 it's really opt-in. Sure, sometimes Google make a SNAFU and break webp support, but if you're on the cutting edge that's what you get.

Let's see what Chrome sends when it requests an image:

  GET /myimage.jpg
  Host: myhost.com
  Accept: image/webp,*/*;q=0.8
  Accept-Encoding: gzip,deflate,sdch
  Accept-Language: en-US,en;q=0.8
That Accept line is part of HTTP Content Negotiation. Chrome is saying "I want that content, and I'd like a webp if you have one. Otherwise whatever you have is fine". Ideally it would list each image type it can handle, so the server can send an appropriate error if a suitable image can't be found. History being what it is though the / is needed.

Alas this isn't really exploited enough, since you'd end up with ridiculous request sizes:

  Accept: image/webp,image/webp+lossless,image/webp+animated,*/*;q=0.8
You can see where that's going...

Accept-Encoding is the one that's used most often. Compression on the server side is very useful to reduce latency, and for static resources it is often free - servers can pre-compress them.

Accept-Language is sadly under-utilised, for the same reason we send dates from the server rather than using the user's clock - people often have misconfigured machines, or are using a friend's computer and don't want to change the language.

There's a lot of things in HTTP, it'd be a shame to reinvent the wheel in JavaScript.

Re: Why Parse the User Agent?

#39

Post by zanny »

timothyb89 wrote: post #17
drivingmenuts wrote: post #9

Yay! Yet another image format that I can't open in Preview, if I save it to my hard drive. Webp may be great for displaying in a web page, but it's TFU if I save it to my hard drive and try to view it with default viewing or editing software. It may not be a proprietary format, but it might as well be.

It hardly seems fair to reject the format simply because Apple hasn't added support for it to their image viewer. At least here my desktop environment happily displayed the saved image with its built-in image viewer (Gwenview). I'll admit that support for the format isn't perfect, but at least in your case it can be remedied pretty easily with a quick search [1]. That said, format adoption has to start somewhere. It'…

Thats odd, I have Gwenview 4.14.2 and qt 4.8.6, and webp doesn't resolve properly. Rekonq can't open it either, but Kolourpaint can and Krita cannot.

Is webp added in qt5?

Re: Why Parse the User Agent?

#40

Post by anon1385 »

I 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 ago when connection speeds were very much slower than today, so the benefit of using it was even greater back then, yet it saw very limited adoption.

Also I note that the saving from using webp compared to the optimised jpeg is only 18kb, meanwhile the page wastes 40kb of bandwidth on a Google analytics script. What Google gives with one hand it takes away with the other.

Post reply on HN