Last Comment Bug 68421 - W3C CUAP: Respect Content-Type HTTP header
: W3C CUAP: Respect Content-Type HTTP header
Status: VERIFIED WORKSFORME
: testcase
Product: Core
Classification: Components
Component: Networking (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: neeti
: Tom Everingham
Mentors:
http://www.w3.org/TR/2001/NOTE-cuap-2...
Depends on: 67646
Blocks: 68427
  Show dependency treegraph
 
Reported: 2001-02-10 01:37 PST by Gervase Markham [:gerv]
Modified: 2011-08-16 04:41 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (155 bytes, text/plain)
2001-02-16 03:54 PST, Stephan Niemz
no flags Details

Description Gervase Markham [:gerv] 2001-02-10 01:37:47 PST
[ This bug is one of the recommendations in the W3C's "Common User Agent 
Problems" document, URL above. One bug has been filed on each recommendation, 
for deciding whether we do it and, if not, whether we should. ]

3.2 Respect the media type of a resource if one is explicitly given using
the Content-Type HTTP header.

     Example:

     If an HTML document is returned with a Content-Type value of
     text/plain, the user agent must render the document as plain text
     without interpreting HTML elements and attributes (i.e. the HTML
     source must be displayed).
Comment 1 Gervase Markham [:gerv] 2001-02-10 02:07:05 PST
Rumour has it that we do this right, so this is WORKSFORME... but 
this needs confirmation by someone in the know.

Gerv
Comment 2 tenthumbs 2001-02-10 13:24:25 PST
People keep filing bugs that suggest mozilla ignore content types under certain
circumstances. Bug 67646 is the most disturbing to me.

I would certainly want mozilla to obey the server except, possibly, under a very
few circumstances and these circumstances would have to be user-specifed.
Comment 3 Stephan Niemz 2001-02-16 03:54:08 PST
Created attachment 25428 [details]
testcase
Comment 4 Stephan Niemz 2001-02-16 03:57:01 PST
I have attached a test case and it works for me with Mozilla 0.8 on NT4.
Marking so.
Comment 5 benc 2001-09-06 09:24:37 PDT
reporter:

This bug is a "futured" or "untargeted" bug which has been "resolved/works for
me". Most bugs meeting this criteria are usually somewhat out of date or working
in the current builds.

If this bug is not happening for you in a recent build (such as the Mozilla
daily build, Mozilla 0.9.3, or Netscape 6.1), please use the friendly "Mark bugs
as VERIFIED" radio button to set this bug to "VERIFIED/WORKS FOR ME"
If you reported the bug on a platform (e.g. Linux) and other contributors
reported on another platform (e.g. Mac OS), please comment that it works for you
 but do not verify it yet.

For these multi-platform bug reports, we need to verify all reported platforms
-OR- create new "still broken on platform X" bugs when you verify.
Comment 6 Gervase Markham [:gerv] 2001-09-06 09:41:44 PDT
Verified.
Comment 7 Reimar Bauer 2011-08-16 04:41:38 PDT
Sorry it did not work for all mimetypes and all kind of item names. 
If we set application/x.moin.download for downloading items it only works for those without an extension. e.g. Image is send with application/x.moin.download and using a name of Image.png ignores that given mimetype. It changes the mimetype because of the extension to image/png.

The reason for using our own mimetype for downloading is that we want to download multiple items in one shot. If the mimetype once becomes accepted by the user he can fetch all items without enabling this download feature for all kind of mimetypeds.

Verified Broken

Note You need to log in before you can comment on or make changes to this bug.