- From: <jg@w3.org>
- Date: Thu, 25 Apr 96 11:29:05 -0400
- 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 UTC