User Agent with Greek characters

Add-ons Add-on Support
#1

Using Firefox Developer Edition version 58.0b4, I tried all User Agent Switcher plugins that allow you to enter a custom user agent string and with non of them I managed to set the user agent to one that contains Greek characters.

This is possible with the plugins that exist for Firefox 56 and Chrome.

I also got the user-agent-rewriter plugin that MDN provides as an example in its webextensions-examples repository on Github, but again, if I enter any Greek characters as a user agent, my user-agent string is ignored and Firefox uses the default user agent.

Is this on purpose, or is it a bug?

#2

The first question is: are Greek characters allowed in a UAS? I don’t know, but take a look at the answers to https://stackoverflow.com/questions/10384741/is-a-unicode-user-agent-legal-inside-an-http-header.

I don’t think Greek is in ISO-8859-1. But that thread is 5 years old so the RFC mentioned may have been superseded. It may need encoding in some way.

#3

Greek is not in ISO-8859-1.

But even if there was such a rule, should Firefox enforce it even when the user wants to use something else? Other browsers (and previous versions of Firefox) do not do this.

#4

RFCs define the internet standards against which all browsers are, or should be, designed. IF the relevant RFC states that the UAS should be ISO-8859-1 (I don’t know whether it does) then I would expect Firefox - or any addon dealing with UAS - to enforce that. It’s not a sensible idea to send an invalid UAS to a webserver - at best it will ignore it.

Just for my information, do you think that a Greek UAS is valid? Have you ever seen a Greek UAS?

#5

No, I never seen Greek in a user agent (apart from my own).

But if Windows Firefox can claim that is Safari on an iPhone or have “asdzdfsadf” as user agent, then I don’t see why I can’t have Greek in a user agent, especially when this can be done with all other browsers including older Firefox.

#6

Well, the difference between “asdzdfsadf” and Greek is that the former is in the ISO-8859-1 character set (indeed it’s ASCII) whereas the Greek isn’t.

On the question of whether a UAS in Greek is valid, I found this in https://tools.ietf.org/html/rfc7230#section-3.2.4 (2014):

Historically, HTTP has allowed field content with text in the
ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
through use of [RFC2047] encoding. In practice, most HTTP header
field values use only a subset of the US-ASCII charset [USASCII].

So it looks to me like Greek - or Chinese or any other international characters - is valid but would have to be encoded as in RFC 2047 (like in email headers.)

I see that the Headers.set() API used by user-agent-rewriter just passes a string. If that string is to be internationalized (Greek or Chinese say) then maybe that has to be done before passing it, or maybe the API should do it. I don’t know which.

Maybe someone else here has a view. If not you could raise a bug against Headers.set that it doesn’t accept foreign characters.