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

Re: svn commit: r38567 - in branches/1.6.x: . subversion/mod_dav_svn

From: Stephen Butler <sbutler_at_elego.de>
Date: Wed, 05 Aug 2009 20:53:35 +0200

Quoting "C. Michael Pilato" <cmpilato_at_collab.net>:

> So, in summary:
> Back in the day we used "text/plain", hard-coded. Then we added mime-type
> lookup, with a fallback of "text/plain". Then we switched to
> ap_default_type() so this could be configurable, but since nobody ever
> bothers to configure that sucker, we were still effectively using
> "text/plain". Then in r36720, we changed to "application/octet-stream"
> because ... an API went away?
> Seems there were three routes that r36720 could have taken:
> 1) return to a hard-coded "text/plain", which preserves the way things
> effectively have been for the past 8 years or so.
> 2) opt not to provide a Content-Type at all, which is how Apache will behave
> as of 2.3 for content not covered by a MIME mapping or ForceType/AddType
> directives.
> 3) do something semi-random, ignoring both the history of this code and the
> direction of the server platform (Apache). We chose this one.
> Now, some perspective. Is this the most critical codepath in the system?
> Does it merit scrutiny of this degree? Perhaps not. It's just that my
> "change-without-good-reason" alarm went off, and I wanted to get to the
> bottom of that.

It was a teachable moment. At least I learned something.

I'll roll back the backport of r36720 to 1.6.x.


Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Received on 2009-08-05 20:53:58 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.