197868 - make mozilla tolerant of Content-Type: text/html\r\r\n

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[Darin Fisher]

Alex Butcher <[e-mail]> wrote:
>
>Hi -
>
>The AstaWare/Innotech Netresults local search engine (as used by O'Reilly &
>Associates for some of their CD Bookshelf titles) has a bug which means it
>issues:
>
>Content-Type: text/html\r\r\n
>
>i.e. an extraneous \r. The attached patch makes Mozilla 1.3 tolerant of this
>using the whitespace trimming mechanism in ParseContentType(). FYI, Netscape
>4.79 at least is similarly tolerant, so please consider applying this patch.
>
>Incidentally, there's also another problem with Netresults and Mozilla;
>Netresults uses HTTP 301 Moved Permanently to redirect the browser to the
>file:// URL of a search results page waiting in /tmp, but Mozilla doesn't
>seem to follow the redirect. I don't personally care much about this, as I
>normally use Galeon, which *does* follow the redirect.
>
>I'd appreciate any feedback or comments you may have. Thanks for a great
>browser!
>
>Best Regards,
>Alex.
>-- Alex Butcher Brainbench MVP for Internet Security: www.brainbench.com
Bristol, UK Need reliable and secure network systems? PGP/GnuPG ID:0x271fd950
<http://www.assursys.com/>
>
>
>
>--- netwerk/protocol/http/src/nsHttpResponseHead.cpp~  2003-03-16
22:40:46.000000000 +0000
>+++ netwerk/protocol/http/src/nsHttpResponseHead.cpp   2003-03-16
22:40:46.000000000 +0000
>@@ -614,7 +614,8 @@
>         p = type + strlen(type);
>
>     // trim any trailing whitespace
>-    while (--p >= type && ((*p == ' ') || (*p == '\t')))
>+    // ...or extraneous CR characters (e.g. AstaWare/Innotech Netresults)
>+    while (--p >= type && ((*p == ' ') || (*p == '\t') || (*p == '\r')))
>         ;
>     *++p = 0; // overwrite first char after the media type

Comment 1

[Matthias Versen [:Matti]]

Have you told him that he should search the mozilla release notes about
"checkloaduri" ?

Comment 2

[Alex Butcher]

No, I hadn't spotted the 'checkloaduri' pref setting. Sorry for not RTFMing.
That fixes the file:// redirection part of my bug report perfectly.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Can this be closed?

Comment 4

[Darin Fisher]

-> default owner

Comment 5

[Alex Butcher]

This seems to have been fixed in Mozilla 1.7.12 (probably a while back), though it does spawn htmlview; not sure if that's correct behaviour or not.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

if you consider spawning htmlview to be the expected/acceptable behaviour, what was the wrong behaviour? comment 0 doesn't say.

Comment 7

[Alex Butcher]

comment 0 doesn't say anything about htmlview because mozilla didn't do anything at all when I filed the bug 3 years ago. Now, it spawns htmlview, which is an improvement. Not quite sure why it can't just render the page directly though, or whether that's better, hence my question.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

ah, ok... I can understand why it wants to handle this externally, probably makes sense to fix that. I don't understand why mozilla didn't use to do anything.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

(with the part about comment 0 I meant that comment 0 didn't say anything about what the actual behaviour is)