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 ...
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2386886
Received on 2009-08-27 00:06:30 CEST