5 ms·

RFC 2616[0] says in section 14.43 that user agents SHOULD send a User-Agent field. Is there any particular reason why it is still sensible to send such a field

RFC 2616[0] says in section 14.43 that user agents SHOULD send a User-Agent field. Is there any particular reason why it is still sensible to send such a field at all, rather than maybe something more generic like ‘Crawler’, ‘Graphical’ and ‘Terminal’ (to distinguish the three cases that might come to mind immediately)? In other words, what benefit does a User-Agent field have nowadays when people are told to check for capabilities rather than products, apart from allowing fancy statistics which company currently has the long^Whighest bar in the user agent statistics? [0] https://www.ietf.org/rfc/rfc2616 https://www.ietf.org/rfc/rfc2616

kijin 14y ago
There are several situations where a web app has no choice but to rely on the user agent string to vary its behavior. For example, when you let a user download a file, you usually send a header such as: Content-Disposition: attachment; filename=FILENAME But what do you do if the filename contains non-ASCII characters? There are RFCs, but every browser has its own rules about encoding, and IE is especially problematic because it tries to second-guess your intentions at every opportunity. You can't use capability detection to solve this problem, because browsers don't execute CSS/JS when they just download files. If you really want to make it perfect for every user, you'll probably need to write a slightly different version of the download script for every browser, and several for IE 6/7/8/9/10. Another valid reason for sniffing the user agent string is when you're trying to offer browser-specific instructions. For example, when you go to Dropbox's download page, they show you how to save and run the installer. They wrote different versions for most of the major browsers/platforms. There are fewer reasons to use the user agent string when you're just trying to compose a web page. But composing web pages is not the only thing you do when you run a web application.
- claudius 14y ago
  I understand the point about browser-specific instructions, but using the User-Agent to decide how to encode a file name sounds…wrong. Imagine your email client checking the email client of the recipient to decide how to encode the file name of the file you attached – sure, it’s nice if it is possible, but in general, standards are supposed to be, well, standards, and not caring about broken software might help motivate vendors to fix it. And even for browser-specific instructions, it would make more sense in my opinion to let users choose the browser for which they want to see instructions[0]: The tool I use to query information is not necessarily the tool I need help with. A bicycle shop also doesn’t decide to only sell shoes or cars if you walk or drive there rather than arriving on a bicycle[1]. [0] I didn’t check Dropbox, so it might well be that they also give people a choice here. [1] Google’s PlayStore specifically annoyed me there recently as it didn’t let me view the description of an extension in Opera, telling me that I would need Chrome to download and use it – I do, but I’d like to know if this extension is worth installing Chrome or not beforehand.
  - jaytaylor 14y ago
    I can vouch for the legitimacy of what he's saying. There are definitely cases where the only way to make browser download operations (whether it be a file download or certain kinds of XHR requests) work right in IE, Chrome, and FireFox is to write a special case for IE or potentially all 3 of them.
  - kijin 14y ago
    > using the User-Agent to decide how to encode a file name sounds…wrong. Of course it's wrong, and web devs wouldn't have to do it in an ideal world. But when your Chinese users complain right now that their attachment names are getting jumbled, and when your conversion rate is going down right now because people don't run the files they've downloaded, does it really matter whose job it is to clean up Microsoft's mess? BTW, non-ASCII attachment names still come out weird from time to time because Outlook, Thunderbird, and various webmails follow different RFCs. Most email composing tools just use a compromise that works 99.9% of the time, but I've seen programs that let you customize the filename encoding.
- pornel 14y ago
  I agree with your point in general, but in that specific case you can use percent-encoded UTF-8 in the URL and send `Content-Disposition: attachment` without filename. In practice index.php/FILENAME trick works in Apache.
randomdata 14y ago
A good client will send a distinguishable user agent because the server may want to reject requests from that client. There is no robots.txt equivalent for user-initiated clients, so user agents are the appropriate way to handle the situation. It is unlikely that you will want to block a traditional web browser, but web browsers are not the only clients available and some will be performing operations that are not necessarily in line with the wishes of your resources.

kijin 14y ago

There are several situations where a web app has no choice but to rely on the user agent string to vary its behavior. For example, when you let a user download a file, you usually send a header such as: Content-Disposition: attachment; filename=FILENAME But what do you do if the filename contains non-ASCII characters? There are RFCs, but every browser has its own rules about encoding, and IE is especially problematic because it tries to second-guess your intentions at every opportunity. You can't use capability detection to solve this problem, because browsers don't execute CSS/JS when they just download files. If you really want to make it perfect for every user, you'll probably need to write a slightly different version of the download script for every browser, and several for IE 6/7/8/9/10. Another valid reason for sniffing the user agent string is when you're trying to offer browser-specific instructions. For example, when you go to Dropbox's download page, they show you how to save and run the installer. They wrote different versions for most of the major browsers/platforms. There are fewer reasons to use the user agent string when you're just trying to compose a web page. But composing web pages is not the only thing you do when you run a web application.

claudius 14y ago
I understand the point about browser-specific instructions, but using the User-Agent to decide how to encode a file name sounds…wrong. Imagine your email client checking the email client of the recipient to decide how to encode the file name of the file you attached – sure, it’s nice if it is possible, but in general, standards are supposed to be, well, standards, and not caring about broken software might help motivate vendors to fix it. And even for browser-specific instructions, it would make more sense in my opinion to let users choose the browser for which they want to see instructions[0]: The tool I use to query information is not necessarily the tool I need help with. A bicycle shop also doesn’t decide to only sell shoes or cars if you walk or drive there rather than arriving on a bicycle[1]. [0] I didn’t check Dropbox, so it might well be that they also give people a choice here. [1] Google’s PlayStore specifically annoyed me there recently as it didn’t let me view the description of an extension in Opera, telling me that I would need Chrome to download and use it – I do, but I’d like to know if this extension is worth installing Chrome or not beforehand.
- jaytaylor 14y ago
  I can vouch for the legitimacy of what he's saying. There are definitely cases where the only way to make browser download operations (whether it be a file download or certain kinds of XHR requests) work right in IE, Chrome, and FireFox is to write a special case for IE or potentially all 3 of them.
- kijin 14y ago
  > using the User-Agent to decide how to encode a file name sounds…wrong. Of course it's wrong, and web devs wouldn't have to do it in an ideal world. But when your Chinese users complain right now that their attachment names are getting jumbled, and when your conversion rate is going down right now because people don't run the files they've downloaded, does it really matter whose job it is to clean up Microsoft's mess? BTW, non-ASCII attachment names still come out weird from time to time because Outlook, Thunderbird, and various webmails follow different RFCs. Most email composing tools just use a compromise that works 99.9% of the time, but I've seen programs that let you customize the filename encoding.
pornel 14y ago
I agree with your point in general, but in that specific case you can use percent-encoded UTF-8 in the URL and send `Content-Disposition: attachment` without filename. In practice index.php/FILENAME trick works in Apache.

randomdata 14y ago

A good client will send a distinguishable user agent because the server may want to reject requests from that client. There is no robots.txt equivalent for user-initiated clients, so user agents are the appropriate way to handle the situation. It is unlikely that you will want to block a traditional web browser, but web browsers are not the only clients available and some will be performing operations that are not necessarily in line with the wishes of your resources.