mudlet-makers team mailing list archive

[Vadim Peretokin <vperetokin@xxxxxxxxx>]

Sounds OK. Should test it with Dropbox that we can still download from
there, that is one of the more popular locations for hosting stuff that
Mudlet scripts download.

On Wed, Sep 10, 2014 at 4:00 AM, Stephen Lyons <1366781@xxxxxxxxxxxxxxxxxx>
wrote:

> Ah, right, well I'll code in "Mudlet/<major>.<minor>" then.
>
> ** Changed in: mudlet
>      Assignee: (unassigned) => Stephen Lyons (slysven)
>
> ** Changed in: mudlet
>    Importance: Undecided => Low
>
> --
> 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     : mudlet-makers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~mudlet-makers
> More help   : https://help.launchpad.net/ListHelp
>

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