W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: Proxy naming

From: Balint Nagy Endre <bne@bne.ind.eunet.hu>
Date: Fri, 6 Oct 1995 00:46:23 +0100 (MET)
To: Larry Masinter <masinter@parc.xerox.com>
Cc: http WG <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <168.bne@bne.ind.eunet.hu>
Larry Masinter writes:
> Paul Leach
> 
> > One small step in this direction would be to allow full URLs in 
> > requests to origin servers in HTTP 1.1. (In HTTP 1.0 and the current 
> > HTTP 1.1 draft, they are only allowed in requests to proxies.)
> 
> Balint Nagy Endre/Andrew:
> 
> > Good idea, but requires a lot of discussion for 1.0-1.1 interoperatibility.
Reconsidered, not too good. See later.
> I think we already had a lot of discussion on this point.  I'm not
> sure there was 100% consensus, but I believe that the sense of the
> group is that HTTP/1.0 and HTTP/1.1 are interoperable, e.g., a
> HTTP/1.0 server should respond to a HTTP/1.1 request and a HTTP/1.1
> server should respond to a HTTP/1.0 request. 
This is OK, except the following scenario:
1.1 client <-> 1.0 proxy <-> 1.1 server.
HTTP 1.0 protocol has two unsolved problems (and they will remain unsolved in
1.0): cache control and content negotiation.
(Recently I put some pages on spike.fa.gau.hu/~bne and my cern proxy ignored
the differences in accept-language. You can try it, using lynx and looking at
http://spike.fa.gau.hu/~bne/Welcome configuring 
preferred_language in .lynxrc once as en and once as hu.)
I think, 1.1 implementors (and users too) will have troubles with those unsolved
problems while 1.0 proxies aren't upgraded. I don't know, there are some
workarounds to avoid the problems or not.
This problematics needs discussions, I think. (Improving 1.1 is less urgent.)
> Adding a Host: field to HTTP 1.1 requests allows interoperability, but
> sending the full URL in the request doesn't. We *should* say that in
> HTTP 1.1, all servers should respond to the full URL, so that future
> versions of the protocol might eliminate "Host:". 
Future version means 3.x? If 1.x should understand 0.9 and 2.x should understand
1.x, then only in 3.0 we can forget the 1.0 version of the protocol.
> Clients could send the full URL to servers where it knew that the
> server was HTTP/1.1 (e.g., had talked to that server/port recently).
The real problem here is:
While Host used in combination with an absolute URL servers will know, that
the user (user agent) thinks the hostname in the host header field value is a
name of this server. 
Using full URLs, when there is some error in the host part, the server is unable
to detect, that there is an incorrect hostname of the server or the server
should act as proxy and there is some (possible transient) DNS error.
In the first case the server may correct the error by doing a fuzzy match on
its names or tell the correct ones if it knows the type of the request. 
(direct vs. proxy)
This requires at forbidding servers acting as proxy and as origin server
at the same time on the same port, but I don't know wether it is a good
idea or not.
Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>
P.S.: the cause of the delay in reply is my poor english knowledge.
     I hope this final version is readable.
Received on Thursday, 5 October 1995 16:56:45 EDT

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