gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] multi-committer functionality revisited


From: Robert Collins
Subject: Re: [Gnu-arch-users] multi-committer functionality revisited
Date: Mon, 24 Nov 2003 09:27:48 +1100

On Mon, 2003-11-24 at 08:19, Tom Lord wrote:
>     > From: Robert Collins <address@hidden>
> 
>     > Sorry, I wasn't clear. This is how url's are formed: there's no choice
>     > about it.
> 
> I don't think so.  Cites?

http://www.faqs.org/rfcs/rfc2396.html

schemes aren't parameterised: they accept parameters in the query_part.

section 5 - the BNF (an extract follows).
scheme ":" scheme-specific-part
scheme= alpha *( alpha | digit | "+" | "-" | "." )

so http-umask is a valid scheme label. http-umask=000 isn't, as = is not 
allowed in the BNF.
That said, section 2 and 2.1 are quite clear - the scheme is a method of
access to the location in question. If you write a cgi-on-http protocol,
which can then be used to obtain access to arbitrary objects, you need a
new identifier.

The key point I am making is that the protocol scheme is not
parameterised under any circumstance. The login part - yes (see below).

>     > A URL as a uniform locator isn't intrinsically client or server side.
>     > Indeed for something like http://, a URL doesn't define *many* aspected
>     > of the request: PUT vs POST ve GET cs SEARCH vs ....
> 
> PUT, POST, GET, etc. are parts of the http protocol.

That was my point: that the actual access being performed by the client
agent to the URL is /not/ fully specified by the url.

> The thing about "sftp%umask=XXX" and "file%umask=XXX" are that they
> are distinct protocols from sftp and file.   sftp%umask requires a
> more elaborate login sequence;  file%umask requires a more elaborate
> translation into system calls.

The are certainly not the file scheme, now that I have revisited it -
file:// has no provision for a query part.

http://www.ietf.org/internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri-01.txt

defines the sftp url - and it has no umask facility (someone from here
may wish to join the wg to help get that in).

That said, I cannot find a umask command for sftp - only a 'lumask'
command which sets the local umask.

You can work around that probably, by running ssh without a tty, then
setting the umask, and finally calling sftp-server.

>     >> The query syntax, on the other hand, modifies the request, not the
>     >> method.
> 
>     > No - it modifies the parameters to be used at the given location.
> 
> They modify the path, not the protocol.  The umask thing modifies the
> protocol.

Right: and thats not permitted by the existing BNF.

>     > Lets debug sftp://host/path/archive?umask=3D007
> 
> Is there a formal spec of sftp-method URLs?   What does it say about
> query syntax?   I'd expect that path+query to be passed verbatim to
> an sftp server.

See above.

Essentially: we were both wrong.

I've had my head up the http spec too long :}.

So I propose the following:
1) Contact the sftp uri WG and get a umask facility added to the
sftp-parameter list.
2) Contact the sftp authors and get an explicit remote umask option
added to the code.
3) we define a new url scheme file-ext

file_ext_URI = "file-ext://" [host] [;file-parameter=value] [ abs_path ]
with one initially defined parameter: umask
umask sets the umask to be used access the resource at the uri, in any
of the formats accepted by the unix umask command.

As for your conceptual cgi scripts that implement cgi commands, I
maintain that as you're describing a new method for accessing the
resource, a new scheme is appropriate.

Rob


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]