[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r36720 - trunk/subversion/mod_dav_svn

From: Greg Stein <gstein_at_gmail.com>
Date: Tue, 25 Aug 2009 01:52:45 +0000

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
>>>> Log:
>>>> Apache 2.3 removed the ap_default_type() function. The theory here is
>>>> that
>>>> every resource should know its type rather than have one applied by
>>>> default. Mismatches between the actual content-type and one simply
>>>> placed
>>>> onto a resource can lead to vulnerabilities, confusion for the client,
>>>> and
>>>> 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.

Possibly, yah.

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

This is an archived mail posted to the Subversion Dev mailing list.