On Tue, Aug 25, 2009 at 01:04, David Glasser<glasser_at_davidglasser.net> wrote:
> On Mon, Aug 24, 2009 at 9:29 AM, C. Michael Pilato<cmpilato_at_collab.net> wrote:
>> Bert Huijben wrote:
>>>> -----Original Message-----
>>>> From: Greg Stein [mailto:gstein_at_gmail.com]
>>>> Sent: vrijdag 20 maart 2009 16:58
>>>> To: svn_at_subversion.tigris.org
>>>> Subject: svn commit: r36720 - trunk/subversion/mod_dav_svn
>>>> Author: gstein
>>>> Date: Fri Mar 20 08:57:50 2009
>>>> New Revision: 36720
>>>> Apache 2.3 removed the ap_default_type() function. The theory here is
>>>> every resource should know its type rather than have one applied by
>>>> default. Mismatches between the actual content-type and one simply
>>>> onto a resource can lead to vulnerabilities, confusion for the client,
>>>> other unseemly behavior. Thus, the removal of ap_default_type().
>>>> If we can't figure out a good mime type to use, then we'll default to a
>>>> bag o' bytes: application/octet-stream.
>>> It seems this breaks browsing to text files via Firefox.
>>> E.g. browse to http://svn.collab.net/repos/svn/trunk/CHANGES
>>> You see a 'save as' box now, where you used to be able to see the file.
>>> (Browsing to ^/trunk/COMMITTERS works as expected, because this file has an
>>> explicit mime type)
>>> It still works correctly in Internet Explorer, that (by default) guesses a
>>> content type by looking at the content for these generic mime types.
>> Yeah, I guess it would work fine if we set the svn:mime-type property on our
>> CHANGES file, though (to "text/plain"). *shrug*. Extension-less files are
>> always problematic for MIME type stuff. While most of the extension-less
>> files in our tree may be human-readable, it's certainly conceivable that
>> others would have extension-less files in their trees that aren't
>> human-readable. It's a win-lose situation!
> On the other hand, it's an irritating feature of many web browsers
> that there's no way to convince them to view an
> application/octet-stream file inline, whereas an erroneous text/plain
> should still support "save link as". I think using octet-stream as
> the default is likely to overall reduce usability of Subversion.
One thought is to read a chunk from the requested file, throw it at
our binary detection code, and use that to determine
"application/octet-stream" or "text/plain". Not sure how much that
would complicate the code. And even then, it means we could be
returning "text/plain" for things that are XML, HTML, SVG, or ...
Received on 2009-08-27 00:06:30 CEST