We could produce the modification to do this quite easily to comply with
RFC2616 {http://www.ietf.org/rfc/rfc2616.txt} but the questions are:
* should Mudlet's UA string begin with "Mozilla/5.0" - I think it has to, but
it must include additional stuff to make it clear that it is NOT the famous
browser but something with some behaviour in common (which I think is a comment
in '(' ')''s such as "(Mudlet/3.0.0)" ) on the other hand we may wish to limit
the amount of version information for "User Agent Sniffing" to, e.g. no more
than major and minor numbers to prevent too much user information from being
revealed, so what do we choose?
* the second non-comment component seems to be the rendering platform - I'd
need to do more research to pronounce on this but I suspect it may be something
like "WebKit/?.?" so what is the right thing?
* do we need to provide the user with a way to change this string if they so
desire, and know what they are doing?
--
You received this bug notification because you are a member of Mudlet
Makers, which is subscribed to Mudlet.
https://bugs.launchpad.net/bugs/1366781
Title:
Fake useragent string causing 406 Errors on Apache Servers with
default configuration
Status in Mudlet the MUD client:
New
Bug description:
From user Sanaki
On forums {http://forums.mudlet.org/viewtopic.php?f=9&t=4594}:
> downloadFile error 406 issue
>
> Sat Sep 06, 2014 5:14 am
> When attempting to download an image using downloadFile from my personal
server, it's throwing an error 406 message at me ("Not Acceptable", for those
unfamiliar). Fetching the same file from a browser works fine. I grabbed the
communication chain with wireshark to see what's going awry, but I can't see
anything obviously wrong there. Theoretically error 406 should mean the accept
header sent by Mudlet is wrong. Granted, I'm years out of practice when it
comes to dealing with apache, TCP, PHP, etc, but even still I'm wondering if
someone has insight. I noticed Akaya had the same issue here, which was left
unanswered.
> EDIT: I removed a bit of information here because I've identified
the issue, but have no simple solution. This is caused by apache
Mod_Security rule 900095, "Bad UA :: Fake Mozilla Agent". This will be
an issue on any server using the boilerplate Mod_Security rules, and
that includes irreparably most shared hosting providers. Mudlet
identifies itself with the full UA string "Mozilla/5.0". Updating this
to a more accurate UA would appear to fix the issue, though I'm unsure
what that would be. Is this something that can't be adjusted for some
reason?
======
> ... this is http and it's a response to Mudlet using a fake UserAgent
string to identify itself. Technically the 406 isn't an error, it's a perfectly
rational response to an unknown browser that's blatantly lying about what it is.
======
> I seem to have found the solution, though I have yet to test it. In the
source, in TLuaInterpreter.cpp, I believe inserting this line after line 8082
would solve our issue completely:
>> request.setRawHeader("User-Agent", "Mudlet 2.1");
> Now, that UA string can be changed to anything really, as long as
it's something that -isn't- "Mozilla/5.0", which is what it defaults
to. Realistically, if there's a variable accessible from there that
contains the current Mudlet version or such, that would probably be
best, but if so I have no idea where to find it. Or it could just be
"Mudlet".
To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1366781/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~mudlet-makers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~mudlet-makers
More help : https://help.launchpad.net/ListHelp
