User Agent modifications
Edward Z. Yang
extension modifies Firefox's user agent string to add FirePHP to it.
This, however, causes problems with some websites which detect user
agent and cause mischief if the user agent doesn't match.
Additionally, recent versions of Firebug are "always-on", so there's
no way to selectively not send the agent string.
Would it be possible to pass the FirePHP information through another
request header, say, X-FirePHP-Agent=0.0.6.5? That would be great!
Thanks,
Edward
P.S. Please CC my email address.
Christoph Dorn
> extension modifies Firefox's user agent string to add FirePHP to it.
> This, however, causes problems with some websites which detect user
> agent and cause mischief if the user agent doesn't match.
Hmm. You should never use exact matching for the user agent string.
FirePHP adds its signature in a way that *should* not affect any regex
parsers.
Do you have any examples of websites that have problems because of this?
> Additionally, recent versions of Firebug are "always-on", so there's
> no way to selectively not send the agent string.
I had to keep it always on due to some unreliable behavior with FB2.
This will be fixed for FF3 in the near future.
> Would it be possible to pass the FirePHP information through another
> request header, say, X-FirePHP-Agent=0.0.6.5? That would be great!
Possible yes. I am open to entertaining this change. Does anyone else
have any comments about this?
Christoph
Tobias Petry
i never encountered a problem. At normal you only search for parts in
the user-agent everything would make no sense, you would have to
change the script everything a new version exists, and for every OS
I think the actual implementation is ok, but an X-FirePHP-Header would
also be nice, but i see no really need of it.
Christoph Dorn
I agree with this. I am going to leave it the way it is for now unless
anyone can provide any compelling reasons to change it.
Christoph
Edward Z. Yang
> Do you have any examples of websites that have problems because of this?
Apparently, if the user agent doesn't match some unspecified regex,
the website will redirect you to Yahoo! I don't know what kind of
security software they're rolling (something Microsoft IIS/ASP
specific I presume), but FirePHP was the culprit. I'll ping them and
see what they're doing.
> Many extensions and other tools add information to the user agent, and
> i never encountered a problem.
tools, and FirePHP is the only one that twiddles with my user agent.
I fully agree with you all that websites should not be doing exact
matching. It's just that, given disabling an extension, or asking a
website I regularly use to change some esoteric security software, and
you can clearly see which will win out. :-/ Also, user agents tend to
show up in logs, whereas custom headers usually do not. This helps
browser privacy.
Tobias Petry
> show up in logs, whereas custom headers usually do not. This helps
> browser privacy.
Jim
least part of it) and thus is rightly being included in the UA string.
However, I am hearing reports that FirePHP is not consistently
including itself in the UA string which should be looked at, IMO.
Jim
On May 29, 12:45 am, "Edward Z. Yang" <edwardzy...@thewritingpot.com>
wrote:
Christoph Dorn
>> i never encountered a problem.
> I use quite a padre of extension (24), including several developers
> tools, and FirePHP is the only one that twiddles with my user agent.
FirePHP is a bit different to other extensions as it extends the
browsers functionality to recognize additional data in a HTTP response.
I had looked carefully at how this additional capability could be
communicated to the server so that the server will only send the data
when supported.
The user-agent header is the proper place to indicate to the server what
the client can do according to the HTTP spec.
"The User-Agent request-header field contains information about the user
agent originating the request. This is for statistical purposes, the
tracing of protocol violations, and automated recognition of user agents
for the sake of tailoring responses to avoid particular user agent
limitations. User agents SHOULD include this field with requests. The
field can contain multiple product tokens (section 3.8) and comments
identifying the agent and any subproducts which form a significant part
of the user agent. By convention, the product tokens are listed in order
of their significance for identifying the application."
> I fully agree with you all that websites should not be doing exact
> matching. It's just that, given disabling an extension, or asking a
> website I regularly use to change some esoteric security software, and
> you can clearly see which will win out. :-/ Also, user agents tend to
I fully agree with you that asking websites to change their code is not
practical for FirePHP users. I will ensure that in 0.2 FirePHP will only
update the user-agent header when the NET panel is enabled. This will
allow you to use sites that don't treat the header properly as long as
you have your net panel disabled. I am making the assumption that any
site you need FirePHP for is a site you control and you can parse the
user-agent header properly.
> show up in logs, whereas custom headers usually do not. This helps
> browser privacy.
Right but as mentioned above, the user-agent header is the proper place
to indicate browser capabilities. Many other plugins do this as well.
Christoph
Christoph Dorn
Many other plugins do it as well. Take a good look at your server logs.
Christoph
Christoph Dorn
> least part of it) and thus is rightly being included in the UA string.
Right. Thanks for confirming this.
> However, I am hearing reports that FirePHP is not consistently
> including itself in the UA string which should be looked at, IMO.
It is adding itself as long as the extension is enabled. It should not
be adding itself if Firebug is disabled which FirePHP is not able to
consistently detect at this time. This will be fixed soon.
Christoph
Jim
> be adding itself if Firebug is disabled which FirePHP is not able to
> consistently detect at this time. This will be fixed soon.
he is having the following problem:
--Browser is already open w/ FireBug and FirePHP installed and enabled
--Points browser to his site
--Page loads, FirePHP is NOT in UA
--Reloads page
--Page loads, FirePHP IS in UA
IN his case, this is breaking some of the session handling done in
Kohana (which may or may not be questionable). In the broader scope,
though, this is obviously not good if true. If FirePHP is up and
ready to receive, it *should always* be in the UA. I do not currently
have an environment to test or confirm his findings though.
Jim
Christoph Dorn
> Kohana (which may or may not be questionable). In the broader scope,
> though, this is obviously not good if true. If FirePHP is up and
> ready to receive, it *should always* be in the UA. I do not currently
> have an environment to test or confirm his findings though.
Thanks for the detailed report. I'll have some time late next week to
take a good look at this and hopefully fix it properly then.
Christoph