396122 - bloglines.com beta doesn't show feed entries because clearsilver 0.10.15 doesn't parse mime types correctly

Status: RESOLVED INVALID

(Core :: General, defect)

Description

[Adam Guthrie]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091305 Minefield/3.0a8pre

Steps to reproduce:
1. Go to bloglines.com and log in.
2. On the start page, click bloglines.com beta.
3. Log in again and click on one of your feeds to view the entries.

Actual results:
No feed entries are visible.

Expected results:
Feed entries show up as they do in IE 7 and Firefox 2.0.0.6.

The fact that this works in other versions would imply that it's a problem with Firefox. It's probably an already filed issue that's the problem, but it'd be nice to know which one.

Comment 1

[Adam Guthrie]

So, this is essentially the same issue that's going on in bug 392046 (same regression range, etc.). I've e-mailed Bloglines asking them to see if they're using a version of mod_security that contains the bad rule that's causing this to fail.

I'm tempted to move this over to Tech. Evan., but I can't decide whether adhering to some standard is worth breaking every site that's running an older version of mod_security using this rule. In other words, maybe bug 362043 (and friends) should be backed out.

Comment 2

[Ben Lowery]

Hi. I'm an engineer at Bloglines; we're taking a look at the problem from our end. Sadly GPa8 is crashing like mad on the beta...

Comment 3

[Paulo Raponi]

Hi Ben, thanks for your attention..
Like you can see in the bug 392046, the problem can be at mod_security module in the Apache webserver.

Comment 4

[Paul Querna]

I'm also an engineer for Bloglines, and I would like to note that we are not using mod_security -- So I doubt this is related to bug 392046.

Comment 5

[Adam Guthrie]

Attachment: HTTP headers from Bloglines Beta

When I was "debugging" this I traced the regression range to be around the time bug 362043 landed. I've attached the HTTP headers from the site with a "working" and "failing" version of Firefox.

Note that the failing version is causing a HTTP/1.x 401 Authorization Required response. This is what made me think it was due to some security module denying access based on a rule or some sort. Is there anything else Apache-related that could cause this to happen?

Comment 6

[Paul Querna]

It looks like this is caused by the addition of the charset to the Content-Type header on POST:
Content-Type: application/x-www-form-urlencoded;charset=UTF-8

It looks like this exposes a bug in the ClearSilver framework which Bloglines is using, clearsilver-0.10.15/cgi/cgi.c has:
  if (!strcmp(method, "POST"))
  {
    if (type && !strcmp(type, "application/x-www-form-urlencoded"))
    {
      err = _parse_post_form(cgi);
      if (err != STATUS_OK) return nerr_pass (err);
    }

Changing this strcmp to not be so stupid should fix this issue on our end.  I'll hopefully sneak it into our next release.

Comment 7

[Adam Guthrie]

Awesome. Yet another piece of software we can add to the list that broke after bug 362043 landed.

Paul, I'm guessing you'll push whatever patch you make upstream or at least inform ClearSilver of the bug? If you don't have time for this, I'll be glad to shoot them an e-mail.

Comment 8

[Paulo Raponi]

That's works fine in Firefox Beta 1. The problem was solved in Server Side.
I think that we can close this bug.