Re: [RFC PATCH 1/4] Document the HTTP transport protocol

Alex Blewitt [off-list ref] wrote:

Shawn O. Pearce <spearce <at> spearce.org> writes:

quoted

+URL Format
+----------

It's worth making clear here that $GIT_URL will be the path to the repository,

...

Thanks, noted.

quoted

HEX = [0-9a-f]

Is there any reason not to support A-F as well in the hex spec, even if they
SHOULD use a-f?

Consistency.  I'd rather be strict and say HEX is [0-9a-f] and
demand that everyone try to standardize on the lower case form.

This may limit the appeal for some case-insensitive systems.

Given that this particular notation of HEX is *only* used within
the protocol body to describe SHA-1 IDs, it won't make it to the
file system as-is.

A conforming Git implementation would first validate that this is in
fact a SHA-1 ID, likely translate it into a binary representation
(that is collapse the 40 byte hex to a 20 byte binary), and then
reformat it as a file system path if its looking for a loose object.
 

It would also be good to document, like with the git daemon, whether all
repositories under a path are exported or only those that have the magic
setting in the config like git-daemon-export-ok.

This isn't something that matters to the protocol specification.
Its a server access control, not protocol detail.

Really, its an implementation detail of git-http-backend in git.git,
or of the RepositoryResolver and UploadPackFactory in JGit.

Therefore, its not going to be documented in this document.
 

Lastly, it would be good to clarify when the result of this GET/POST exchange
is a text-based (and encoded in UTF-8) vs when binary data is returned; we 
don't want to get into the state where we're returning binary data and 
pretending that it's UTF-8.

Oh, right.

-- 
Shawn.