I ran into a site that we load as plain text and shouldn't have.
Created attachment 83747 [details] [diff] [review] patch Made this patch, but it still doesn't load it, still plain text
The server sent back the following headers: HTTP/1.1 200 OK Date: Wed, 15 May 2002 22:10:30 GMT Server: Apache/1.3.24 (Unix) PHP/4.2.0 mod_perl/1.26 mod_ssl/2.8.8 OpenSSL/0.9.6b Last-Modified: Thu, 18 May 2000 21:31:37 GMT ETag: "7fc34-3d58-39246139" Accept-Ranges: bytes Content-Length: 15704 Connection: close Content-Type: text/plain It's sending the page as text/plain, not text/html.
Yeah, we're doing the right thing here (so this should go to evang, imo). That said, adding "shtm" to all those places may well be a good idea anyway....
Assignee: new-network-bugs → darin
Component: Networking → Networking: HTTP
QA Contact: benc → httpqa
this isn't a networking:http bug. it is perhaps a mime handling bug. -> file handling (seems like the closest component)
Assignee: darin → law
Component: Networking: HTTP → File Handling
QA Contact: httpqa → sairuh
Like I said in comment 3, that patch is probably a decent idea but useless for that site... sr=me on the patch except the bogus change to printPageSetup.dtd. That said, the nsIWindowsHooks.idl comments seems very odd to me (the second chunk in that file).
nsbeta1- per the nav triage team.
Keywords: nsbeta1 → nsbeta1-
Assignee: law → nobody
QA Contact: chrispetersen → file-handling
Should we still do this ? The URL is 404 and the server itself doesn't seem to have this bug anymore.
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.