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

Stephen Butler wrote:
> I guess the mainstream browsers are taking the mime-type they're
> given, nowadays.

I suspect it's more the case that mainstream browsers have better mime-type
guessing logic and so don't need a web server to provide an inverified
Content-Type.

>> The question then is whether the content and expectations of a typical
>> static HTTP root are significantly different from the content and
>> expectations of a typical Subversion repository.
>
> The background:
>
> In olden times, if a file's svn:mime-type property was not set,
> Subversion's mod_dav_svn set its mime-type to 'text/plain'.
>
> In r14262 this was changed to let mod_mime attempt to set the
> mime-type. The fallback was still 'text/plain'.
>
> It was suggested to use Apache's ap_default_type() (IIUC, the
> DefaultType directive) as the fallback, instead of 'text/plain'.
> Recorded as issue 2304 and fixed for 1.5.0 in r22897.
>
> In r36720 this was changed to use 'application/octet-stream' as the
> fallback, because ap_default_type() is gone.
>
> If I understand the Apache issue above, when mod_dav_svn is running
> in Apache 2.3+, it shouldn't set a fallback mime-type. At least,
> ideally it wouldn't. I don't suppose we have an equivalent to
> APR_VERSION_AT_LEAST for Apache?

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.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2380548