233259 - text/plain pages rendered as application/octect-stream

Status: RESOLVED WONTFIX

(Core Graveyard :: File Handling, defect)

Description

[Jesus Cea]

User-Agent:       
Build Identifier: 

Reproducible in build 20040205. Mozilla 1.6 works fine.

Reproducible: Always
Steps to Reproduce:
1. Go to http://www.argo.es/~jcea/wikis/irc-dev/LogsDelCanalEnero2004

2. Choose any date.

3. Launch a network sniffer.

3. Mozilla shows a dialog box telling that the page has a
"application/octect-stream" MIME type.

4. Look at the network sniffer's output. You'll see a "text/plain" MIME type.

Actual Results:  
A dialog box to choose a location to save a "binary" file.

Expected Results:  
Show the plain page.

Comment 1

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

heh. this is due to bz/ben's patch - the file does indeed use non-ascii
characters, it seems (vim shows them like ^A).

Comment 2

[Boris Zbarsky [:bzbarsky]]

So the page includes bytes with the values "0x01", "0x02", "0x03".

These are most definitely not ISO-8859-1, of course.

At the same time, this page is _not_ served up by Apache.  It's served up by Zope.

Possible options:

1)  Wontfix this bug
2)  Add a check that the server is Apache
3)  Add a check that the URI has an extension (in this case it does not, and I
    can't think of many cases when a file with no extension would be expected to
    be "gotten right", since IE will get them wrong).

Thoughts?

Comment 3

[timeless]

this is funny

The following links:
Jueves 1 - Sábado 3 - Jueves 8 - Lunes 12 - Martes 13 - Miércoles 14 - Viernes
16 - Domingo 25 - Martes 27 

(and only the preceding links, not any of the other links on the page)

cause IE6.0.2800.1106 <long list of update versions> to toss up a dialog:

File Download                                                              [x]

 _  Some files can harm your computer. If the file information below
(?) looks suspicious, or you do not fully trust the source, do not open or
 `  save this file.

        File name: irc-dev-20040101
        File type:
        From:      www.argo.es


    Would you like to open the file or save it to your computer?

    [    &Open    ]  [[    &Save    ]]  [    Cancel    ]  [    &More Info    ]

    [x] Al&ways ask before opening this type of file

--
Anyone happen to have any idea *why* it's those specific links?

Comment 4

[Malcolm Rowe]

Wontfix would be my vote. RFC 2046 implicitly disallows some control characters 
(0-31, 127 excluding HT, FF, CR, LF) in text/* content unless another 
specification overrules it - the specific text/{x} type, the charset, or 
a 'private agreement'. That's my reading of section 4.1.2, anyway.

So the server is serving content that can't possibly be valid as 'text/plain' 
content, but claiming that it is. I don't see how this is materially different 
to the 'server sends binary file as text/plain' Apache problem, except that 
this case is caused by a server-side application problem (presumably) rather 
than a bone-headed default in the standard configuration file.

Oh, the other difference, of course, is that this is *meant* to be text. It 
clearly isn't text/plain, though.

Comment 5

[Jesus Cea]

You (all) are right. And I agree that this would be "won't fix".

In fact, I'm serving "binary" content as a "text/plain" mime type. With previous
mozilla build it worked fine, so my confusion. I was not aware of similar
problems under Internet Explorer, since I don't use that browser (Mozilla rules!
:-).

I'll change my content to proper and real "text/plain".

Thanks all. Response had been amazing. Thanks again.

Comment 6

[Hixie (not reading bugmail)]

Should we have a bug on the fact that we _claim_ the server called it 
application/octect-stream?

Ideally we should really say something to the effect that the server claimed the 
file was text/plain but the file couldn't have been text/plain... :-)

Comment 7

[Boris Zbarsky [:bzbarsky]]

Yeah, that may be a good idea.  File it, please?