You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bert Huijben <rh...@sharpsvn.net> on 2009/08/24 16:23:15 UTC
RE: svn commit: r36720 - trunk/subversion/mod_dav_svn
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: vrijdag 20 maart 2009 16:58
> To: svn@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.
Bert
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2386773
RE: Re: svn commit: r36720 - trunk/subversion/mod_dav_svn
Posted by Julian Foad <ju...@btopenworld.com>.
I filed issue #3508 <http://subversion.tigris.org/issues/show_bug.cgi?id=3508> in order to have something to refer to. Note that the issue is already fixed and the fix is expected to be available in release 1.6.6.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2404103
Re: svn commit: r36720 - trunk/subversion/mod_dav_svn
Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Stein wrote:
> On Thu, Sep 3, 2009 at 09:25, C. Michael Pilato<cm...@collab.net> wrote:
>> anatoly techtonik wrote:
>>> I've stumbled across the same misbehaviour.
>>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2387122
>>>
>>>
>>> Is there any bugreport for this already to be notified when this will be
>>> fixed?
>> I committed a fix (restoring "text/plain" as the fallback MIME type)
>> yesterday, and have proposed that change for backport to Subversion 1.6.x.
>
> Yah... even tho it might be "wrong" in some pedantic sense, I think
> the change back to text/plain was warranted. Thanks for staying on top
> of this!
I think we should propose a new standard MIME type to indicate that the
Content type is entirely unknown: "something/shrug"
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2391031
Re: svn commit: r36720 - trunk/subversion/mod_dav_svn
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Sep 3, 2009 at 09:25, C. Michael Pilato<cm...@collab.net> wrote:
> anatoly techtonik wrote:
>> I've stumbled across the same misbehaviour.
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2387122
>>
>>
>> Is there any bugreport for this already to be notified when this will be
>> fixed?
>
> I committed a fix (restoring "text/plain" as the fallback MIME type)
> yesterday, and have proposed that change for backport to Subversion 1.6.x.
Yah... even tho it might be "wrong" in some pedantic sense, I think
the change back to text/plain was warranted. Thanks for staying on top
of this!
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2390942
Re: svn commit: r36720 - trunk/subversion/mod_dav_svn
Posted by "C. Michael Pilato" <cm...@collab.net>.
anatoly techtonik wrote:
> I've stumbled across the same misbehaviour.
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2387122
>
>
> Is there any bugreport for this already to be notified when this will be
> fixed?
I committed a fix (restoring "text/plain" as the fallback MIME type)
yesterday, and have proposed that change for backport to Subversion 1.6.x.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2390646
RE: Re: svn commit: r36720 - trunk/subversion/mod_dav_svn
Posted by anatoly techtonik <te...@gmail.com>.
I've stumbled across the same misbehaviour. http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2387122
Is there any bugreport for this already to be notified when this will be fixed?
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2387159
Re: svn commit: r36720 - trunk/subversion/mod_dav_svn
Posted by "C. Michael Pilato" <cm...@collab.net>.
Johan Corveleyn wrote:
> On Mon, Aug 24, 2009 at 9:29 AM, C. Michael Pilato<cm...@collab.net>
> wrote:
>> 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!
>
> Note that not only extension-less files are affected currently. All the
> *.txt files under trunk/notes are also returned with "Content-Type:
> application/octet-stream", causing FF to popup its dialog to open or save
> the file.
Hrm. I thought that would only happen if a mime.types lookup failed to find
anything for .txt files. (Though, ISTR that this only works if Apache is so
configured, and I might not have svn.collab.net so configured.)
> Forgive my ignorance, but I don't really understand why this has changed.
> The old behavior was consistent with the way SVN considers files as
> text-files for diffing and merging. I.e. if a file has no mime-type svn
> will perform textual merges etc. (same as when it has a mime-type of
> text/*). Or am I wrong?
If by "this has changed", you mean "the code was touched at all", that was
due to an Apache API that we depended on going away.
If by "this has changed", you mean "the default of text/plain was changed
application/octet-stream", then I don't think gstein (who made the change,
and with good intent) actually realized he was changing an established default.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2387128
RE: svn commit: r36720 - trunk/subversion/mod_dav_svn
Posted by Johan Corveleyn <jo...@uz.kuleuven.ac.be>.
On Mon, Aug 24, 2009 at 9:29 AM, C. Michael Pilato<cm...@collab.net> wrote:
> 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!
Note that not only extension-less files are affected currently. All the *.txt files under trunk/notes are also returned with "Content-Type: application/octet-stream", causing FF to popup its dialog to open or save the file.
Forgive my ignorance, but I don't really understand why this has changed. The old behavior was consistent with the way SVN considers files as text-files for diffing and merging. I.e. if a file has no mime-type svn will perform textual merges etc. (same as when it has a mime-type of text/*). Or am I wrong?
So I would consider it normal to fall back on text/plain as a Content-Type if there is no mime-type set. Or maybe, as Daniel suggested, send no Content-type (don't know if that would work for all browsers though)...
Kind regards,
Johan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2387036
Re: svn commit: r36720 - trunk/subversion/mod_dav_svn
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Would browsers behave differently if we sent *no* content-type header for
those files (instead of sending an explicit "application/octet-stream"
header)?
David Glasser wrote on Mon, 24 Aug 2009 at 18:04 -0700:
> On Mon, Aug 24, 2009 at 9:29 AM, C. Michael Pilato<cm...@collab.net> wrote:
> > Bert Huijben wrote:
> >>> 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.
> >>
> > Yeah, I guess it would work fine if we set the svn:mime-type property on our
> > CHANGES file, though (to "text/plain").
>
> 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.
>
> --dave
>
>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2386976
Re: svn commit: r36720 - trunk/subversion/mod_dav_svn
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Aug 25, 2009 at 01:04, David Glasser<gl...@davidglasser.net> wrote:
> On Mon, Aug 24, 2009 at 9:29 AM, C. Michael Pilato<cm...@collab.net> wrote:
>> Bert Huijben wrote:
>>>> -----Original Message-----
>>>> From: Greg Stein [mailto:gstein@gmail.com]
>>>> Sent: vrijdag 20 maart 2009 16:58
>>>> To: svn@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
Re: svn commit: r36720 - trunk/subversion/mod_dav_svn
Posted by David Glasser <gl...@davidglasser.net>.
On Mon, Aug 24, 2009 at 9:29 AM, C. Michael Pilato<cm...@collab.net> wrote:
> Bert Huijben wrote:
>>> -----Original Message-----
>>> From: Greg Stein [mailto:gstein@gmail.com]
>>> Sent: vrijdag 20 maart 2009 16:58
>>> To: svn@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.
--dave
--
glasser@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2386877
Re: svn commit: r36720 - trunk/subversion/mod_dav_svn
Posted by "C. Michael Pilato" <cm...@collab.net>.
Bert Huijben wrote:
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein@gmail.com]
>> Sent: vrijdag 20 maart 2009 16:58
>> To: svn@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!
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2386777