Ben Collins-Sussman <sussman@collab.net> writes:
>
> FOUND some bogusness! I'm pretty sure this is the problem.
>
> Lookee here at this ethereal trace on the failed "GET" that we're
> seeing when you try to checkout the head of /clients/rapidsvn:
I think we found the other bogusness too, on the PROPFIND:
GET /repos/svn/!svn/ver/2766/clients/rapidsvn/trunk/src/res/bitmaps/versioned_folder.ico HTTP/1.1^M
User-Agent: neon/0.21.2 SVN/0.14.0 (dev build)^M
Keep-Alive: ^M
Connection: TE, Keep-Alive^M
TE: trailers^M
Host: svn.collab.net^M
^M
HTTP/1.1 200 OK^M
Date: Mon, 29 Jul 2002 15:00:11 GMT^M
Server: Apache/2.0.40-dev (Unix) DAV/2 SVN/0.14.0 (dev build)^M
ETag: "2766//clients/rapidsvn/trunk/src/res/bitmaps/versioned_folder.ico"^M
Accept-Ranges: bytes^M
Content-Length: 894^M
Keep-Alive: timeout=15, max=100^M
Connection: Keep-Alive^M
Content-Type: "image/x-icon"
^M
^M
[intended beginning of response body...]
(Note, the ethereal output has *real* ^M's, not these phony ones
above.)
Notice that the mime-type property doesn't have the ^M on the same
line, like one normally sees at the bottom of a header-block, (or at
the end of any normal header line). I suspect that somebody edited
this property with 'svn propedit' and snuck an extra newline (LF) in
the propvalue. And now, of course, this regresses to the previous
problem. An extra byte is being counted as part of the body when it
shouldn't be.
I think we need to be *very* careful setting the svn:mime-type
property, since it has the ability to effect the validity of our
network protocol. Let's talk about solutions. Karl has ideas:
1. The client should validate the propval at set-time.
Also,
2. The server should validate the propval before throwing it into the
headers.
Our validation simply needs to check that the value is "header safe".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 29 18:50:56 2002