W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: 5.1.2 Request-URI

From: <jg@w3.org>
Date: Thu, 25 Apr 96 11:29:05 -0400
Message-Id: <9604251529.AA09897@zorch.w3.org>
To: Dave Kristol <dmk@allegra.att.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>> 5.1.2 says:
>>              Request-URI    = "*" | absoluteURI | abs_path
>> 
>> The intent is to require a specific form of absoluteURI, but the syntax
>> at 3.2.1:
>>              absoluteURI    = scheme ":" *( uchar | reserved )
>> allows something much broader.
>>
>> What can/should we say about "scheme"?
>
>It's clear I wasn't clear about what I meant to say....
>
>I would think that for the *http* specification, particularly for an
>origin server, there are the following additional requirements that
>are currently unstated:
>
>- absoluteURI must be an http_URL (3.2.2)

I don't think so.  Proxies also act as gateways between protocols,
so a client that only knows how to do HTTP can still get resources
in other protocols (e.g. ftp, gopher, etc.).  If you make this
requirement, then you require all clients to have native access
support.  This seems bad to me.

>- (should https_URL and shttp_URL also be mentioned?)

And whatever URL type comes up in the future?  Seems best to be silent,
rather than restrictive.  Not to mention the problem of referencing 
non-standards documents.

>- host must be the FQDN of the host to which the request is sent

Now this makes some sense to me; to require the FQDN in any URL type
This is the last trace of the host problem.  I'm not familiar enough with
all the specs to say if we have the situation right in the collection
of HTTP related specs.

Editorial comment here:  It is often good practice not to over-specify
something, which might make an implementation non-compliant for no
perceptible good reason (we have the example in the first situation
above).  Conversely, when you specify something precisely,
which may be needed for interoperable implementations, you must
fully understand all the consequences. For example, the broken (esthetically
ugly) wide lines and arcs in the X Window System are the result 
of a simple and  precise specification the consequences of which were 
not fully understood until after the fact; we ran into what was
still a research problem without realizing it.  You can get burned both ways.

				- Jim
Received on Thursday, 25 April 1996 08:35:05 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:51 EDT