83611 - Content-Type: "Text/HTML" needs to be handled w/ caps insesitivity

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect, P1)

Description

[tor]

Steps to reproduce:
  * start mozilla
  * type "www.ashford.com" into the urlbar and hit enter

Result:
  * dialog offering to download text/html from http://www.ashford.com/

Expected result:
  * ashford page loaded in browser

Additional data:
  * ashford server returns these headers:

HTTP/1.1 200 OK
Set-Cookie: WEBTRENDS_ID=128.148.38.166-2338432848.29420112; expires=Fri,
31-Dec-2010 00:00:00 GMT; path=/
Server: Microsoft-IIS/5.0
Date: Fri, 01 Jun 2001 04:08:42 GMT
Connection: Keep-Alive
Content-Type: Text/HTML
Accept-Ranges: none
Pragma: no-cache
Expires: 0
Content-Length: 38396

Comment 1

[Chris Hiner]

Dup of bug 81576 or one of the side problems of bug 82236.

Comment 2

[doctor__j]

I would guess it's a dupe of bug 81576

But check out the content type first:
> Content-Type: Text/HTML

Should it be "text/html"?  (Is Moz case sensitive to mime types?)

Comment 3

[neeti]

Changing platform to all. this happens on windows too

Comment 4

[neeti]

Darin: should we be converting the content-type to lower case in 
nsHttpResponseHead::ParseContentType(..) before we assign it to mContentType?

Comment 5

[Darin Fisher]

yes.. that's got to be it!  let's get this fixed for 0.9.2.

Comment 6

[jkng]

I don't know if this is related or not, but when I close a window that has
trouble connecting to a site (the striped bars in the load status keeps on
churning), the download dialog comes up.

Comment 7

[doctor__j]

[e-mail] has just mentioned a reliable way of reproducing the bug.

On modem connection, I sometimes need to close the
stall/inactive/no-network-activity window and then afterwards the connection is
made and the prompt is popped up asking me how to handle text/html stuff.

IOW, the connection is not killed after closing the corresponding window.

Comment 8

[neeti]

Attachment: attaching patch

Comment 9

[neeti]

gagan, darin: could you r= and sr= this patch?

thanks,
neeti

Comment 10

[Gagan]

since we are already walking the string to clean out trailing whitespaces 
(backwards till non-whitespace) on these lines--

445     while (--p >= type && ((*p == ' ') || (*p == '\t')))
446         ;

I'd suggest we extend that to translate each character to lowercase all the way 
till p==type. Would save us the copy/construct of nsCAutoString. Make sense?

Comment 11

[Darin Fisher]

how about something like this:

     while (--p >= type && ((*p == ' ') || (*p == '\t')))
         ;
     *++p = 0; // overwrite first char after the media type
+
+    // force the content-type to lowercase
+    while (--p >= type)
+        *p = nsCRT::ToLower(*p);

     mContentType = type;

Comment 12

[Matthias Versen [:Matti]]

*** Bug 84198 has been marked as a duplicate of this bug. ***

Comment 13

[chris hofmann]

any chance of this getting moved into 0.9.1?

Comment 14

[chris hofmann]

moving to 0.9.1 until we hear.

Comment 15

[Aleksey Nogin]

See also bug #59619 "MIME types should not be case sensitive".

Comment 16

[neeti]

Attachment: attaching new patch

Comment 17

[neeti]

darin, gagan: I have attached the new patch. could I get a r= and sr= on this.

Comment 18

[Gagan]

r=gagan and this is a small fix but relatively useful one! I'd say lets try and 
get it in for 0.9.1 Since the patch is pretty consistent with darin's suggestion 
I'd say assume sr from him too and get this in asap.

Comment 19

[Darin Fisher]

sr=darin

Comment 20

[neeti]

fixed checked in to the branch

Comment 21

[chris hofmann]

a=chofmann

Comment 22

[lchiang]

ben, pls verify on the branch builds (from afternoon today) when you get a
chance.  thanks.

Comment 23

[Tom Everingham]

taking care of this for ben

marking as fixed

Comment 24

[Tom Everingham]

verified fixed on afternoon builds: 

WinNT 2001060614-0.9.1
Linux rh6 2001060613-0.9.1
Mac os9 2001060614-0.9.1

a quick look showed that this fixed at least one of the dupes, checking them 
next

Comment 25

[tor]

Reopening - I don't see this checked in on the trunk.

Comment 26

[Mike Jaques]

its in on the 091 branch, lets get it in on the trunk to get it completely off 
teh radar.  Closing in on no 091 bugs, 5 left including this one. Sorry for the 
spam, but someone just check it in :)

Comment 27

[Tom Everingham]

yeah, my mistake for marking fixed/verified.  Adding vtrunk keyword.

Comment 28

[neeti]

fix checked into the trunk

Comment 29

[benc]

I got trunk verifications. Thanks for the help, Tom.

Comment 30

[benc]

VERIFIED:
Mozilla 0.9.5, allplats
-vtrunk