[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: Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA_at_GMail.Com>
Date: Wed, 5 Aug 2009 23:17:43 +0200

2009-08-05 20:53:35 Stephen Butler napisał(a):
> 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.

r36720 had 3 +1 votes. I suggest to not revert anything and wait for possible
better solution. r36720 at least fixed build failure.

-- 
Arfrever Frehtes Taifersar Arahesis

Received on 2009-08-05 23:16:50 CEST

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