Re: Save/Open dialog
Boris Zbarsky
> In the download manager it has a "Open" link
> that opens the downloaded file with the mime handler associated with
> the mime type discovered through mime sniffing of the file.
Only with some (very recent) GNOME versions, and only for some file types. For
example, XML-based types are handled very poorly in this case, because they all
sniff as XML.
> 1) Sometimes the file is in /tmp, sometimes the file is in ~/Downloads
The ones in /tmp are the ones we'll delete on quit, for what it's worth.
> 2) Sometimes the file will get opened with the wrong app, if the
> webserver is misconfigured.
And sometimes it'll get opened with the wrong app from the download manager, if
it's an XML-based type.
Not to mention that the GNOME versions that do less sniffing would screw up .rpm
files (is that a RealPlayer file, or a RedHat Package Manager file)?
> Wouldn't it be better to just download straight to ~/Downloads (or
> ~/Downloads/Unfinished maybe) and if the user wants to open the
> document let them click open in the download manager?
This requires an extra click on the user's part to open the file, no?
> This way we're reliably opening the the right program for the file
I question that we're "reliably opening the right program"; see above.
-Boris
Ray Strode
On 6/25/07, Boris Zbarsky <bzba...@mit.edu> wrote:
> Ray Strode wrote:
> > In the download manager it has a "Open" link
> > that opens the downloaded file with the mime handler associated with
> > the mime type discovered through mime sniffing of the file.
>
> Only with some (very recent) GNOME versions, and only for some file types. For
> example, XML-based types are handled very poorly in this case, because they all
> sniff as XML.
It's actually been true for quite a while (since gnome 2.8, gnome's at
2.18 now).
> > 2) Sometimes the file will get opened with the wrong app, if the
> > webserver is misconfigured.
>
> And sometimes it'll get opened with the wrong app from the download manager, if
> it's an XML-based type.
Well, that's a bug we have the ability to fix (with shared-mime-info
updates). We can't fix every misconfigured webserver out there.
> Not to mention that the GNOME versions that do less sniffing would screw up .rpm
> files (is that a RealPlayer file, or a RedHat Package Manager file)?
Actually, that example is one of the things that webservers get wrong a lot.
> > Wouldn't it be better to just download straight to ~/Downloads (or
> > ~/Downloads/Unfinished maybe) and if the user wants to open the
> > document let them click open in the download manager?
>
> This requires an extra click on the user's part to open the file, no?
No, not really. Remember the dialog won't exist anymore so that saves
a click or two.
> > This way we're reliably opening the the right program for the file
>
> I question that we're "reliably opening the right program"; see above.
While, the freedesktop mime system may not be perfect, it's at least
fixable, and the results will be more consistent with file managers,
etc.
--Ray
Boris Zbarsky
> In my opinion it would be better for the health of the web for us to use
> the server-provided type when opening
I would like to expand on this, just so we're on the same page.
The proposal on the table is basically to ignore server-provided MIME types
completely in favor of client-side sniffing by the OS.
If this is implemented, then only types that the OS knows about can be handled
with helper apps. In particular, if I want to create a new unregistered MIME
type with the "x-" prefix, distribute a helper app for it, and make it
available, users won't be able to use my new file type unless their OS knows
about it.
Now OS vendors (including Linux distributions) can't be reasonably expected to
include all types that anyone out there is using in their OS configuration.
They would include, at best, all the registered types and the popular
unregistered ones. Which not only makes the OS vendors gatekeepers to the sorts
of content that users can access, but also means that only content that is either:
a) Already popular.
or
b) Being pushed by someone with money and/or influence (needed to get
things registered, from what I can see).
Thus this setup serves to perpetuate the status quo and stifle innovation by
anyone who doesn't already have said money/influence.
I think this is almost diametrically opposed to the Mozilla Foundation's goals.
Something about:
The mission of the Mozilla project is to preserve choice and
innovation on the Internet.
See also <http://www.mozilla.org/about/>.
-Boris
-Boris
Ray Strode
> In particular, if I want to create a new unregistered MIME
> type with the "x-" prefix, distribute a helper app for it, and make it
> available, users won't be able to use my new file type unless their OS knows
> about it.
Apps are free to register new mime types with the OS. They can:
1) drop an xml file in /usr/share/mime/packages then run
update-mime-database /usr/share/mime
or
2) submit a patch against /usr/share/mime/packages/freedesktop.org.xml
upstream to shared-mime-info
I think the second approach is the approach that's pushed for the most
(it means the OS can recognize what type the file is even if the
corresponding helper isn't installed), but the first approach should
work fine too.
> Now OS vendors (including Linux distributions) can't be reasonably expected to
> include all types that anyone out there is using in their OS configuration.
> They would include, at best, all the registered types and the popular
> unregistered ones.
Right, that's what the data in shared-mime-info is.
--Ray
Christopher Aillon
> If this is implemented, then only types that the OS knows about can be handled
> with helper apps. In particular, if I want to create a new unregistered MIME
> type with the "x-" prefix, distribute a helper app for it, and make it
> available, users won't be able to use my new file type unless their OS knows
> about it.
Actually, this is incorrect. See
http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec
You just need to perform the right incantations to register your type
with the OS and your helper app with the type. Ray can fill in details
here.
Boris Zbarsky
> Apps are free to register new mime types with the OS. They can:
>
> 1) drop an xml file in /usr/share/mime/packages then run
That's world-writable? Or do you have to be root to try out an app?
> 2) submit a patch against /usr/share/mime/packages/freedesktop.org.xml
> upstream to shared-mime-info
Which means that users of, say, FC5 still lose?
One other thing to keep in mind. In general, any time we treat data as anything
but the type advertised in the Content-Type header we introduce potential
security holes due to us bypassing content-filtering proxies. We do this in a
very few cases where it was deemed absolutely necessary and where IE is known to
do the same (e.g. text/plain), but doing it on a blanket basis would require
some heavy-duty convincing on the security end.
-Boris
Christopher Aillon
> Ray Strode wrote:
>> Apps are free to register new mime types with the OS. They can:
>>
>> 1) drop an xml file in /usr/share/mime/packages then run
>
> That's world-writable? Or do you have to be root to try out an app?
If it's not writable, the app can and should install to
~/.local/share/mime instead.
Gervase Markham
> Trying to get the summary of my last three interactions with helper app
> UI redesigns into a public forum so I never have to retype this. I'm
> probably not going to respond further to this thread, because I just
> don't have the time to go through this whole thing again (esp. since I
> have little faith in me being able to convince people, based on those
> previous three experiences).
FWIW, I think I agree with everything you've said. So you've convinced
at least one person :-)
Gerv
Boris Zbarsky
First, the "Open" option is also used for cases when there is no helper
application -- to launch executables. Note that some things (e.g.
perl/sh/python/whatever scripts) somewhat blur the line here. On Linux, as a
user, I'd think of a Perl file as an executable in its own right (because Perl
is basically always installed), but on Windows it's definitely something that
needs a helper app.
Second, a security-conscious user (which is very few, I know) is likely to want
to use different helper apps for content that comes from the Internet (call it
"untrusted") and content that's already on his computer ("trusted"). This could
range from using the --safe option to "gv" for untrusted PostScript files to
using a Word document viewer without macro support for untrusted content (while
using MS Word for local Word files) to using a Perl interpreter trusted perl
files and using a text editor for untrusted ones.
OSes don't have great support for multiple context-dependent handlers for a
given file type, which is why we need to allow setting a non-default handler in
the helper app UI. The question is what should happen when "Open" is clicked,
given the "launch executables" thing above. Should the default handler for the
type be used? Note the Perl situation.
-Boris
Christopher Aillon
> As I see it, the following are requirements for any good file handling setup on
> all platforms:
>
> * Handling is largely determined by the server-provided MIME type
> (for files over HTTP). Exceptions should be few, far between, and
> made for very very good reasons.
I strongly disagree here. Windows/IE have had several security issues
because they trusted the website to issue the correct MIME type. I see
no reason to trust the MIME type which can just be accidentally wrong
(such as Real vs RPM) or intentionally modified to be wrong to exploit
some hole. The important bit is what's in the file, not what the server
reports it as. The Content-Type header is a good guideline, but we
cannot rely on it being accurate.
> * When encountering a new MIME type the app must allow the user to
> choose what to do with it (with appropriate default choices available).
> Defaulting to doing things without ever prompting the user leads to
> security bugs (or the sort of thing that happened back when "lpr" was
> the default PostScript viewer on RedHat).
The user wants to view it for the most part. Imagine how annoying the
internet would be if every time you clicked on a hyperlink, the browser
asked whether you wanted to view or save the URL. It is not an
unreasonable default to always view, and if the default apps need to get
a save option, then we can fix that (for the record evince already has
grown one recently).
Additionally, I strongly feel that the browser, and applications in
general, should not work around bugs in the OS. We refuse to do it for
the NULL deref issue, I see no reason to do so for a lesser security issue.
> * One of the options for handling a MIME type should be "treat it as
> this other type". For example, users should be able to treat
> text/x-c++ as text/plain and just have it open an editor or open
> in the browser.
The freedesktop spec has an inheritance chain built in. In the official
implementation, text/x-c++ *does* inherit from text/plain which if we
used the spec, we could take advantage of. I would really like to see
this happen so I don't need to download c source or DTDs or whatnot to
disk before viewing.
IFF we allow users to say "treat as foo", it really should be something
the user twiddles on in about:config: 99% of users will have no idea
about any of this stuff. Though I'd question the need since the small
percentage of people who would know enough about this stuff also can
figure out other ways of doing things. But allowing the user to own
themselves by treating random type as executable, or even maybe some
image formats, etc. is probably something that we will regret.
> * There app should remember the choice made above and present it as
> the default-selected choice the next time this MIME type is
> encountered.
And what if the choice was wrong? Users in general, especially on the
linux side might not know what the applications are. My father just
used a computer at the library for the first time. The word "Acrobat"
means about as much to him as "evince" does to a first time Linux user.
He just wanted to open the file because he needed to print and fill
out his citizenship forms. His first inclination was to open the file
in Word, assuming it would work.
> * There must be a way to tell the app to just perform this
> default-selected choice without the need for extra user
> interaction. Exceptions can be made here for catch-all types
> like application/octet-stream.
We should be avoiding interaction by default. Users will click thru
whatever default selected stuff without looking at it, so there's no
point in asking them. If they want to change things, we should help
them do that.
> * All access points to opening a file do the same thing with it
> (be it "Open" links in the download manager or whatever).
> * It must be clear from all such access points exactly which application
> will be used to open the file. Optionally all such access points should
> have a way of selecting a different application to use.
Some users care which application it opens with. Do all? Do most? For
the users that do, do they really want to tell each and every app what
to do in the event it encounters XYZ file?
What about system administrators? Do they need to modify Firefox to use
their preferred program, then also modify Thunderbird. Then go modify a
few other applications and then finally the OS? Seems like setting
this up at the application level is the wrong approach to me.
> * When saving, the (partial) file should be placed in the final download
> location as early as possible, possibly with a slightly modified name.
Agree.
> * Extensions should not be used as the primary key for helper apps
> anywhere in the UI (because of collisions like the "rpm" one).
Agreed, there are far too many collisions here.
But should MIME types be the key? Just like extensions, they CAN be and
often times ARE wrong. Who's going to fix all the IIS servers out there
to return proper types? Or force sys admins to update their apache?
These servers are the epitome of machines that get updated infrequently.
Even going through bugzilla, I find that people often upload things with
incorrect MIME types. Should that matter? I want to view the
attachment, but instead I must first edit the type, then view it. (Or
download to disk, then view it)
Additionally, if this is truly a cross platform issue, then there is
really nothing we can do here. If we try to, we'll end up getting it
right for some OSes and wrong for others and/or expending far too much
energy trying to re-invent a wheel. We really ought to defer to the OS,
and push bugs back to the OS. Trusting millions of web servers to
return the right thing is much more difficult and error-prone than
trusting a few OSes to do the right thing.
Jean-Marc Desperrier
> I strongly disagree here. Windows/IE have had several security issues
> because they trusted the website to issue the correct MIME type. I see
> no reason to trust the MIME type which can just be accidentally wrong
> (such as Real vs RPM) or intentionally modified to be wrong to exploit
> some hole. The important bit is what's in the file, not what the server
> reports it as. The Content-Type header is a good guideline, but we
> cannot rely on it being accurate.
You got it fully reversed. Windows/IE have had severe security issues
because they considered the important bit is what's in the file, instead
of what the server reports it as. That has caused major security
problems, whereas Firefox behavior only of using only Content-Type only
results in inconvenience.
Also Windows/IE make it for example impossible to deliberately display
an HTML file as raw text by sending it as text/plain.
The Content-Type header not being accurate is a major problem, but it's
a major problem of the server, and that's where it needs to be solved.
Even if the fact web server today almost only have file extensions
available to determine file-type makes it a really hard problem.
But trying to solve it at the client level only creates more difficulties.
L. David Baron
> I strongly disagree here. Windows/IE have had several security issues
> because they trusted the website to issue the correct MIME type. I see
I recall security issues because they ignored the MIME type from the
server. I don't recall any of the reverse.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
Bob Clary
> On Tuesday 2007-06-26 13:05 -0400, Christopher Aillon wrote:
>> I strongly disagree here. Windows/IE have had several security issues
>> because they trusted the website to issue the correct MIME type. I see
>
> I recall security issues because they ignored the MIME type from the
> server. I don't recall any of the reverse.
>
If I may chime in here as someone who fought the good fight over server
reported contents types back prehistoric prefirefox days.
<http://bclary.com/log/2004/09/26/boot-camp-content-type> sums up my
understanding of our former position. It contains a link to
<http://www.google.com/search?hl=en&lr=lang_en&ie=UTF-8&safe=off&as_qdr=all&q=%22internet+explorer%22+mime+site%3Asecuritytracker.com&btnG=Search&lr=lang_en>
which illustrates some of the content sniffing issues IE and MS have had
over the years.
I must admit I was a little bothered by the feed detection, but this is
even more bothersome. I'll let you fight out the details, but I will
state my personal opinion of an absolute requirement: ZERO security
issues due to content sniffing.
Bob
Christopher Aillon
> On Tuesday 2007-06-26 13:05 -0400, Christopher Aillon wrote:
>> I strongly disagree here. Windows/IE have had several security issues
>> because they trusted the website to issue the correct MIME type. I see
>
> I recall security issues because they ignored the MIME type from the
> server. I don't recall any of the reverse.
>
http://www.microsoft.com/technet/security/bulletin/MS01-020.mspx for one.
Christopher Aillon
> Christopher Aillon wrote:
>> I strongly disagree here. Windows/IE have had several security issues
>> because they trusted the website to issue the correct MIME type. I see
>> no reason to trust the MIME type which can just be accidentally wrong
>> (such as Real vs RPM) or intentionally modified to be wrong to exploit
>> some hole. The important bit is what's in the file, not what the server
>> reports it as. The Content-Type header is a good guideline, but we
>> cannot rely on it being accurate.
>
> You got it fully reversed. Windows/IE have had severe security issues
> because they considered the important bit is what's in the file, instead
> of what the server reports it as.
I was thinking of
http://www.microsoft.com/technet/security/bulletin/MS01-020.mspx
> The Content-Type header not being accurate is a major problem, but it's
> a major problem of the server, and that's where it needs to be solved.
The problem with servers is that these are the types of machines that
don't really ever get upgraded. Once you get a server working, you just
maintain it with security patches and touch it as little as possible.
Realistically, the problem will never go away on the server side, as
there will always be new types coming out faster than servers can keep
up. We offer free upgrades to customers.
> Even if the fact web server today almost only have file extensions
> available to determine file-type makes it a really hard problem.
> But trying to solve it at the client level only creates more difficulties.
Yeah, it is rather difficult to maintain the database of available
types[1]. But it is difficulty that is not endured by Firefox as this
is at the freedesktop.org level. The database is either trusted or not
and Firefox can choose to use it or not.
[1]
http://webcvs.freedesktop.org/mime/shared-mime-info/freedesktop.org.xml.in?view=markup
Mike Hommey
> And what if the choice was wrong? Users in general, especially on the
> linux side might not know what the applications are. My father just
> used a computer at the library for the first time. The word "Acrobat"
> means about as much to him as "evince" does to a first time Linux user.
> He just wanted to open the file because he needed to print and fill
> out his citizenship forms. His first inclination was to open the file
> in Word, assuming it would work.
By the way, if the vast joke of the "Other" application selection could
be removed, too. Or replaced by an actual useful list of applications,
and then maybe for the perverts, some way to browse the filesystem. But
having to choose between a default application and going through the
filesystem to find another suitable application is a joke.
Mike
Christopher Aillon
> Realistically, the problem will never go away on the server side, as
> there will always be new types coming out faster than servers can keep
> up. We offer free upgrades to customers.
The final sentence was meant to read:
We offer free upgrades to customers but they still prefer to avoid
change as long as possible. Any change is a destabilizing act in the
view of the server admin, including such non-intrusive changes as fixing
server MIME types.
L. David Baron
> L. David Baron wrote:
> >> I strongly disagree here. Windows/IE have had several security issues
> >> because they trusted the website to issue the correct MIME type. I see
> >
> > server. I don't recall any of the reverse.
> >
>
> http://www.microsoft.com/technet/security/bulletin/MS01-020.mspx for one.
Based on my reading, that's not about honoring vs. ignoring MIME
types; it's about handling a particular MIME type (which could just
as easily have been a particular extension) as meaning "execute this
file".
Christopher Aillon
> I must admit I was a little bothered by the feed detection, but this is
> even more bothersome. I'll let you fight out the details, but I will
> state my personal opinion of an absolute requirement: ZERO security
> issues due to content sniffing.
As someone on various security teams, I agree a thousand times over.
But Mozilla should not assume responsibility for OS issues (unless of
course someone wants to start the Moz OS thread up again).
Boris Zbarsky
> I strongly disagree here. Windows/IE have had several security issues
> because they trusted the website to issue the correct MIME type.
There is no question of "correct" here. The type is whatever the site says; you
have no way to know whether this is just a new format that you don't know
anything about. Sniffing it is just bad.
I'd love to see references to these security issues, though.
> I see no reason to trust the MIME type
Please see my earlier post about Mozilla foundation goals, etc.
> The user wants to view it for the most part.
Agreed.
> Imagine how annoying the internet would be if every time you clicked on a hyperlink, the browser
> asked whether you wanted to view or save the URL.
This is why I said "new MIME type". One that you have never seen before.
> It is not an unreasonable default to always view, and if the default apps
Did you read the part about why we can't trust the default apps?
> Additionally, I strongly feel that the browser, and applications in
> general, should not work around bugs in the OS.
Sorry, but that would be screwing our users over.
> We refuse to do it for the NULL deref issue
We don't have a good way to work around it that I can see. And I'm in favor of
working around that one, if you check the relevant bugs.
> The freedesktop spec has an inheritance chain built in.
Again, you're assuming that you have a complete list of types. You don't. Get
over that assumption, please. Also, you will note that my post was not
OS-specific. If Linux provides a way to do what we want without UI on our part
(not that it does, mind you), so much the better.
> But allowing the user to own
> themselves by treating random type as executable
Sure. There are restrictions on some of this to do with security. If I had
gone into all the security considerations, my mail would have been many times
the length.
> or even maybe some image formats
How is that different from the site just sending that data in an <img>?
>> * There app should remember the choice made above and present it as
>> the default-selected choice the next time this MIME type is
>> encountered.
>
> And what if the choice was wrong?
Then the user changes it the next time, no? Unless they said "don't ask me
again". In which case we don't have good UI for it (certainly not in Firefox).
I'm not about to start proposing UI details -- that's not a strong point of mine.
> My father just used a computer at the library for the first time. The word "Acrobat"
> means about as much to him as "evince" does to a first time Linux user.
> He just wanted to open the file because he needed to print and fill out
> his citizenship forms. His first inclination was to open the file in
> Word, assuming it would work.
So the browser prompted him to open in Acrobat and he overrode that and selected
Word? Or something else?
> We should be avoiding interaction by default.
We've had security holes that way, sorry. Things like "ActiveState Perl is the
default handler for .pl files" and similar issues on Linux. If we detected all
such cases, I'd be happier with having the default action Just Happen.
> Users will click thru whatever default selected stuff without looking at it
True. So we need a better solution here.
> Some users care which application it opens with. Do all?
No.
> Do most?
Depends on the data, probably.
> For the users that do, do they really want to tell each and every app what
> to do in the event it encounters XYZ file?
I'm happy for us to save these preferences in whatever the Approved Format Of
the Day is. Used to be mailcap, and Netscape used to save things there (and
read things from there). Arguably, that was the right behavior and one we
should come back to.
Of course that presupposes that you have a separation between the way apps that
talk to the outside world handle stuff and the way your file manager does. Such
a separation is really needed, and I don't see it existing.
> Seems like setting this up at the application level is the wrong approach to me.
I agree, but it's the best we can do with the hooks the OS is providing.
I'd really rather all the internet-oriented apps just used mailcap for content
off the net, frankly, until people get a better system in place, but it's years
too late for that.
> But should MIME types be the key? Just like extensions, they CAN be and
> often times ARE wrong.
It's a different issue. Extensions are not only "wrong", but fundamentally
ambiguous. MIME types are not.
> Even going through bugzilla, I find that people often upload things with
> incorrect MIME types.
In almost all cases where I've seen this, it's bugzilla's type sniffing screwing
up. I wouldn't be surprised if it's using a MIME database of exactly the sort
we're talking about here.
> Additionally, if this is truly a cross platform issue, then there is
> really nothing we can do here.
I see no reason this UI should be the same across all OSes. In fact, it already
isn't -- for the same content on different OSes users are allowed to do very
different things with it. For example, you don't even get a chance to open a
file with the .bat extension in the default handler on Windows.
> We really ought to defer to the OS, and push bugs back to the OS.
We should do that too, sure. But our upgrade cycles is much faster than the OS
upgrade cycle for all the actual users I've ever met (even more so on
non-Linux), so while we might eventually end up in OS nirvana, it'll take a
while to get there for all our users.
-Boris
Boris Zbarsky
> By the way, if the vast joke of the "Other" application selection could
> be removed, too. Or replaced by an actual useful list of applications,
You mean like on Windows? At least that's how it should be there, since it's
certainly possible; if it's not, it's just a bug.
> and then maybe for the perverts, some way to browse the filesystem. But
> having to choose between a default application and going through the
> filesystem to find another suitable application is a joke.
Yes, indeed. If the OS would provide us with a list of applications, we should
use it.
-Boris
Boris Zbarsky
> I was thinking of
> http://www.microsoft.com/technet/security/bulletin/MS01-020.mspx
That sounds like they screwed up and ShellExecuted something without changing
the extension.
Note that content doesn't determine what happens on Windows. Extension does.
Also note that there is no way to tell apart a malicious .bat file apart from
any text file by looking at the content.
-Boris
Christopher Aillon
>> Seems like setting this up at the application level is the wrong approach to me.
>
> I agree, but it's the best we can do with the hooks the OS is providing.
Are there any hooks that the fd.o stuff is specifically lacking?
>
> I'd really rather all the internet-oriented apps just used mailcap for content
> off the net, frankly, until people get a better system in place, but it's years
> too late for that.
Yeah, fd.o mime stuff is supposed to be the better system... I disagree
that it's too late, though. :-)
Boris Zbarsky
> Are there any hooks that the fd.o stuff is specifically lacking?
Yes. What's needed is a way to have separate helpers for trusted and untrusted
files. Often the same, sometimes different.
e-mail programs, web browsers, etc should use the untrusted versions (and
possibly provide UI for the user to change them, with hooks available for apps
to save these user decisions). File managers should use the trusted versions.
-Boris
Gervase Markham
> I was thinking of
> http://www.microsoft.com/technet/security/bulletin/MS01-020.mspx
The bug here, according to that advisory, is that:
"However, a flaw exists in the type of processing that is specified for
certain unusual MIME types. If an attacker created an HTML e-mail
containing an executable attachment, then modified the MIME header
information to specify that the attachment was one of the unusual MIME
types that IE handles incorrectly, IE would launch the attachment
automatically when it rendered the e-mail."
IE incorrectly handles certain MIME types.
The attacker sets the MIME type in order to exploit the bug. IE handled
the content appropriately for the type; it's just that the handler had a
flaw. This is equivalent to us correctly passing off audio/x-ms-wma to
Media Player and it having a buffer overflow.
> The problem with servers is that these are the types of machines that
> don't really ever get upgraded. Once you get a server working, you just
> maintain it with security patches and touch it as little as possible.
This is indeed a problem. But it doesn't magically make the server not
be the right place for the fix.
> Realistically, the problem will never go away on the server side, as
> there will always be new types coming out faster than servers can keep
> up. We offer free upgrades to customers.
Why is the mime type definition file not in a separate package, which
can be updated standalone (and with an extra override file that users
can edit for their install)?
Gerv
Jean-Marc Desperrier
> Any change is a destabilizing act in the
> view of the server admin, including such non-intrusive changes as fixing
> server MIME types.
The solution would an *easy* way for anyone who uploads files to tell
the server what mime type value to use for them. Without causing any
overload that will motivate the admin to disable that feature. Without
requiring any other feature that the admin might want to disable to be
enabled.
Mike Hommey
> Mike Hommey wrote:
> > By the way, if the vast joke of the "Other" application selection could
> > be removed, too. Or replaced by an actual useful list of applications,
>
> You mean like on Windows? At least that's how it should be there, since it's
> certainly possible; if it's not, it's just a bug.
IIRC, on Windows, you have a small list of applications that could be
used to read the mime type, and the same "Other" choice : picking by
yourself in the filesystem. No way to get a list of useful applications
not related to the mime type.
> > and then maybe for the perverts, some way to browse the filesystem. But
> > having to choose between a default application and going through the
> > filesystem to find another suitable application is a joke.
>
> Yes, indeed. If the OS would provide us with a list of applications, we should
> use it.
I don't remember which application does, but I've certainly already seen
a list of applications under Gnome. I guess gnome has an API for that.
Mike
Alexander Sack
> On Tue, Jun 26, 2007 at 08:37:23PM -0500, Boris Zbarsky <bzba...@mit.edu> wrote:
> > use it.
>
> a list of applications under Gnome. I guess gnome has an API for that.
In nautilus use "Open with Other Application ..." to get:
http://people.ubuntu.com/~asac/Screenshot-Open-With.png
Is that what you have seen?
- Alexander
Mike Hommey
> On Wed, Jun 27, 2007 at 08:35:31AM +0200, Mike Hommey wrote:
> > On Tue, Jun 26, 2007 at 08:37:23PM -0500, Boris Zbarsky <bzba...@mit.edu> wrote:
> > > use it.
> >
> > a list of applications under Gnome. I guess gnome has an API for that.
>
> In nautilus use "Open with Other Application ..." to get:
>
> http://people.ubuntu.com/~asac/Screenshot-Open-With.png
>
> Is that what you have seen?
Yes, exactly.
I took a quick look at the code, and saw the nsGNOMERegistry component could use
http://library.gnome.org/api/gnome-vfs-2.0/2.6/gnome-vfs-20-gnome-vfs-mime-database.html.en#gnome-vfs-mime-get-all-applications
instead of (or in addition to)
http://library.gnome.org/api/gnome-vfs-2.0/2.6/gnome-vfs-20-gnome-vfs-mime-database.html.en#gnome-vfs-mime-get-default-application
for a start.
Mike
Boris Zbarsky
> IIRC, on Windows, you have a small list of applications that could be
> used to read the mime type, and the same "Other" choice : picking by
> yourself in the filesystem. No way to get a list of useful applications
> not related to the mime type.
I'm pretty sure I've seen that filed, for what it's worth. Too bad no one
bothered to fix it.
> I don't remember which application does, but I've certainly already seen
> a list of applications under Gnome. I guess gnome has an API for that.
Sounds like we should make use of it, then. Bug filed?
-Boris
Gervase Markham
> The solution would an *easy* way for anyone who uploads files to tell
> the server what mime type value to use for them.
OSes can supply this information on the upload, using the Content-Type.
Servers can also ask for it explicitly if they choose, using whatever
web-based UI they want to provide. See Bugzilla for an example.
Gerv
Dan Mosedale
> [Cross-posting to dev.a.firefox, since this is not really Linux
> specific, but followups go to dev.platforms.linux.]
>
> Trying to get the summary of my last three interactions with helper app
> UI redesigns into a public forum so I never have to retype this.
Thanks; this is very helpful. I've added a link to this thread to bug
377782. Note that while a bunch of the design work has already
happened, the implementation is not likely to happen before Firefox 3.
So when we do get to that point, we'll be able to come back to this
thread and make sure we've taken all the stuff we need to into account.
> As I see it, the following are requirements for any good file handling
> setup on all platforms:
>
> * Handling is largely determined by the server-provided MIME type
> (for files over HTTP). Exceptions should be few, far between, and
> made for very very good reasons.
Unless I'm misunderstanding something, section 4.7 of the WhatWG HTML 5
draft appears to mostly disagree with the above statement. See
<http://www.whatwg.org/specs/web-apps/current-work/#content-type-sniffing>
for details. The WhatWG mailing list seems like a much better place to
have the sniffing-vs-server-type discussion than this thread.
Dan
Dan Mosedale
> Mike Hommey wrote:
>> IIRC, on Windows, you have a small list of applications that could be
>> used to read the mime type, and the same "Other" choice : picking by
>> yourself in the filesystem. No way to get a list of useful applications
>> not related to the mime type.
>
> I'm pretty sure I've seen that filed, for what it's worth. Too bad no
> one bothered to fix it.
Bug 348808; it's scheduled to be fixed for Firefox 3.
Dan
L. David Baron
> Boris Zbarsky wrote:
> > * Handling is largely determined by the server-provided MIME type
> > (for files over HTTP). Exceptions should be few, far between, and
> > made for very very good reasons.
>
> Unless I'm misunderstanding something, section 4.7 of the WhatWG HTML 5
> draft appears to mostly disagree with the above statement. See
> <http://www.whatwg.org/specs/web-apps/current-work/#content-type-sniffing>
> for details. The WhatWG mailing list seems like a much better place to
> have the sniffing-vs-server-type discussion than this thread.
I think that's largely because Hixie is under the impression that
all browsers do sniffing, which isn't the case quite as much as he
thinks.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Boris Zbarsky
>> * Handling is largely determined by the server-provided MIME type
>> (for files over HTTP). Exceptions should be few, far between, and
>> made for very very good reasons.
>
> Unless I'm misunderstanding something, section 4.7 of the WhatWG HTML 5
> draft appears to mostly disagree with the above statement.
Not at all. That section says that you use the server-provided type unless one
of the following is true:
1) The server-provided type is text/plain
2) There is no server-provided type
3) The server-provided type is an image type
4) The server-provided type is text/html
In case 1 the browser should sniff whether the file is actually binary.
In case 2 the browser should sniff the type.
In case 3 the browser should sniff the actual image type from the magic number.
In case 4 the browser should sniff for an RSS feed.
We do all four, although we only do case 3 for <img> tags and not for loads in a
docshell. I doubt we'd want to change that, frankly.
This would be "exceptions are few" as far as I'm concerned. Certainly a far cry
from sniffing _everything_ that we don't handle internally.
-Boris
Gervase Markham
> Boris Zbarsky wrote:
>> (for files over HTTP). Exceptions should be few, far between, and
>> made for very very good reasons.
>
> Unless I'm misunderstanding something, section 4.7 of the WhatWG HTML 5
> draft appears to mostly disagree with the above statement. See
> <http://www.whatwg.org/specs/web-apps/current-work/#content-type-sniffing>
> for details. The WhatWG mailing list seems like a much better place to
> have the sniffing-vs-server-type discussion than this thread.
I'm not sure they are so far apart. The WHAT-WG section seems to say to
use the server MIME type, except in a number of limited cases:
1) Allow one supported image type to be served as another one (4.7.3)
2) Do binary-sniffing for text/plain, with a possible switch to
application/octet-stream only (4.7.1)
3) Try and sniff feeds served as text/html (4.7.4)
4.7.5 says "Extensions must not be used for determining resource types
for resources fetched over HTTP." So it's Content-Type or sniffing only.
Gerv
L. David Baron
> On Thursday 2007-06-28 14:48 -0700, Dan Mosedale wrote:
> > Boris Zbarsky wrote:
> > > (for files over HTTP). Exceptions should be few, far between, and
> > > made for very very good reasons.
> >
> > Unless I'm misunderstanding something, section 4.7 of the WhatWG HTML 5
> > draft appears to mostly disagree with the above statement. See
> > <http://www.whatwg.org/specs/web-apps/current-work/#content-type-sniffing>
> > for details. The WhatWG mailing list seems like a much better place to
> > have the sniffing-vs-server-type discussion than this thread.
>
> all browsers do sniffing, which isn't the case quite as much as he
> thinks.
Scratch that, and see other responses. It's only describing
sniffing in the cases where most/all browsers do actually do it, I
expect.
Jean-Marc Desperrier
But we are foremost talking about http servers where the served file are
stored on the file system. Not that it would necessarily be bad to
radically change the way this works still.
Dan Mosedale
> Scratch that, and see other responses. It's only describing
> sniffing in the cases where most/all browsers do actually do it, I
> expect.
Yeah; I misread. Sorry about that.
Dan
Hixie
>
> > Unless I'm misunderstanding something, section 4.7 of the WhatWG HTML 5
> > draft appears to mostly disagree with the above statement.
>
> Not at all. That section says that you use the server-provided type unless one
> of the following is true:
> 3) The server-provided type is an image type
> In case 3 the browser should sniff the actual image type from the magic number.
>
> docshell. I doubt we'd want to change that, frankly.
If you visit this URI, you'll see a cat:
http://www.hixie.ch/tests/adhoc/http/content-type/images/001.gif
...despite the fact that it is labelled as image/gif but is really a
PNG.
--
Ian Hickson
Boris Zbarsky
> If you visit this URI, you'll see a cat:
>
> http://www.hixie.ch/tests/adhoc/http/content-type/images/001.gif
>
> ...despite the fact that it is labelled as image/gif but is really a
> PNG.
Ah, I misread the image sniffing section. "Supported by the user-agent" is key.
Note that Gecko sniffs more than just gif/png/jpeg, last I checked...
-Boris