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

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

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

Changing platform to all. this happens on windows too

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

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

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.

jkng@visto.com 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.

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

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?

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;

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

any chance of this getting moved into 0.9.1?

moving to 0.9.1 until we hear.

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

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

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.

sr=darin

fixed checked in to the branch

a=chofmann

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

taking care of this for ben marking as fixed

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

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

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

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

fix checked into the trunk

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

VERIFIED: Mozilla 0.9.5, allplats -vtrunk