Comment 9 for bug 34758

On Tue, Aug 21, 2007 at 08:36:45AM +0100, Matt Zimmerman wrote:
> On Tue, Aug 21, 2007 at 04:04:52AM -0000, Stuart Bishop wrote:
> > We trust the mime type sent by the browser. So at the moment it is
> > garbage in, garbage out.
>
> I wonder what's confusing Firefox, then. These files don't look like HTML
> to file(1), for example.
>
> Alexander, can you tell us how the detection works?

I think its a mix from file-extension and file-introspection .... for
details I would have to investigate ... which I didn't because read
below ...

>
> > If it is only a case of text/plain being sent as text/html, can we
> > special case this in the Librarian? I can't think of a use case where we
> > *want* to store HTML in the Librarian and have it served up as HTML. So
> > we can make the Librarian serve HTML mime types as text/plain or better
> > yet store them in the database as text/plain on upload. I think we need
> > to do this one day anyway, as if the Librarian starts doing
> > authentication it will become a source of attacks.
>

It looks like that this is not true. What I did: I downloaded your
gdm.log from bug 126797 ... uploaded the .log file to some random test
bug 121740 and captured the headers.

And see: launchpad thinks its text/html ... but the headers log reveals
that firefox sends the gdm.log mime-part as text/x-log (e.g. no
text/html) ... so I suspect that launchpad falls back to text/html if
it doesn't know about the mimetype send by the browser (however just
guessing).

FYI, attached the captured header log.

> It seems like it should be possible to store HTML in the librarian and
> record it as such, though I agree that it doesn't make sense to serve it
> that way.
>

IMHO, all mime-types in the text/* hierachy should just be served as
text/plain ... I might miss some corner cases where we want
something different though.

 - Alexander

 �c��