httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: absoluteURIs suck
Date Sat, 21 Feb 1998 23:57:53 GMT
>See <>.

Semantics are always more important than performance and bandwidth
efficiency.  It was my job to work on semantics while excluding any
consideration of efficiency, because it was someone else's task to
do a tokenized version of the protocol (in parallel with my work).
The only thing I did in that regard was make sure the resulting protocol
was friendly to tokenization (which HTTP/1.1 certainly is).

Nothing gets done in this world without a champion to do the real work.
Tokenization of HTTP failed because there wasn't someone pushing it
in the same way that I pushed the HTTP/1.x process (pushed it so hard
that I made many enemies in the process).  Every time I hear a complaint
about HTTP efficiency, my only response is: where were you when HTTPng
dropped off the face of the earth?

The pisser of it all is that people often portray the designers of
HTTP/1.x as being ignorant of efficiency issues.  Crikey, I could have
designed and implemented a binary HTTP in a month's work, and will
probably have to soon just to shut people up.  I would have done so a long
time ago if it weren't for the fact that the Apache architecture isn't
capable of it yet, and I don't want to do it alone.  That is, BTW, why
I added the Upgrade header field to HTTP/1.1.

>> Either the server is configured to deal with the global namespace, or
>> it ignores the global namespace assuming that every request it receives
>> is intended for it.
>This is not a requirement of RFC2068.  And it's not a requirement of
>Apache either.  Section 1.3:
>    ...any server may act as an origin server, proxy, gateway, or tunnel,
>    switching behavior based on the nature of each request.

That's what I meant -- it is a configuration issue.

>My complaint is absoluteURI.  Let me examine the possibilities for
>recognizing a domain name as your own server (so that you can
>determine if it's a proxy request or an origin request):
>- DNS lookup, trust the IP returned, and if it matches the local
>    connection IP then say "that's me".  This is a seriously broken
>    method -- not only for performance, but for denial of service
>    and security reasons.  Apache currently DOES implement this,
>    and I want to get rid of this.  It's bad doing a forward
>    lookup, the attackers control forward lookups.

Sorry, I don't follow this at all.  The server has an IP address and
a port.  If you can't trust it, you can't trust your OS.  A DNS lookup
is not necessary.

>- Exhaustive listing of servernames.  Apache tries these lists first
>    before doing the DNS lookup.  But it is impossible to exhaustively
>    list servernames precisely because it is the client that decides
>    how a hostname maps to an ip address, not the server.

It is the server that decides what hostnames to consider as its own,
not the client.  If the hostname is broken, fix it.  If the client
sends the wrong thing, tell the client to piss off.  If there is some
weird DNS config somewhere that causes all your normal names to look
like something else, then add those names as aliases to your server
config.  There is nothing here that can't be solved by a proper host
configuration and lookup.

>Insert my rant here about how name-vhosts are an inaccurate protocol.
>I'd love something like this inserted into the standard:
>    Note that the server may resolve DNS in a different manner than
>    the client.  For example, a client requesting
>    the unqualified hostname www may resolve it to
>    If the server happens to be managed by the CS dept, it may resolve
>    an unqualified www as  A client making a request
>    to www then may not result in the correct origin server.  To avoid
>    problems such as this clients SHOULD fully qualify all domain names
>    specified by the user.

And as I explained to the http-wg many times, the client is getting
what it asked for.  If you don't like ambiguity, don't use ambiguous

>At any rate, to fix the check_fulluri in apache is going to require an
>extra field in the request_rec.  When doing check_fulluri apache has no
>idea that it's handling an origin request or a proxy request.

It'll probably require more than that.  It is one of the things on my
list of architectural changes for 2.0 (actually, the first one I put on
about two years ago).

And yes, Via (what was originally called "Forwarded", but later changed
to a minimum syntax for efficiency) does avoid request loops.


View raw message