Subject: HTTP Request Forwarding?

From: "Mike Schinkel" <[email-masked]>
Date: Thu, 8 Mar 2007 00:16:20 -0500

Hi all:

I notice renewed activity on the HTTP spec and thought I would ask about
what I would call "HTTP Request Forwarding."  As far as I know HTTP doesn't
support (but I sure would be glad to found out I misread the specs, if I
did!).  I wrote a blog post describing it and giving a use-case at [1].

Basically, what I'm asking is:

1.) Did I misread the spec, and HTTP Request Forwarding actually is
offered?, and 

2.) If Request Forwarding is not currently part of the HTTP spec are there
any potential security issues that would make adding it impossible?, and 

3.) Is it possible to discuss including Request Forwarding init the HTTP
spec?

BTW, I posted to both [email-masked] and [email-masked] because I
didn't know where was appropriate; if someone can direct me to the list that
is most appropriate of the two I'd appreciate it. 

Thanks in advance.

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org - http://t.oolicio.us

[1] http://blog.welldesignedurls.org/2007/03/08/http-request-forwarding/

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 08 Mar 2007 18:27:35 +1300

in your scenario the underlying TCP protocol doesn't allow server C to 
reply to A on the existing connection between A and B.

if you wanted A to think the resource from C is really coming from B, 
then B would need to proxy the request through to C, and forward the 
response back through its connection.

if the HTML resource contained image tags on a different server that 
server B really wanted A to ask it for instead, it would need to 
re-write the HTML that was being sent back to the client.

this is how CGI proxies work for instance, they re-write the content 
passing through them so that subsequent requests (anchor and image tags) 
come back through them.

I'm sure there are some special cases that don't work with this approach.

Adrien

---

From: "Mike Schinkel" <[email-masked]>
Date: Thu, 8 Mar 2007 00:52:50 -0500

Adrien de Croy wrote:
> if you wanted A to think the resource from C is really coming 
> from B, then B would need to proxy the request through to C, 
> and forward the response back through its connection.

Thanks for the reply.  That is what is critical to avoid. 

If TCP/IP can't do this jow does SIP do it?  

An alternate would be a reply that goes back to the client that says:

	"This URL is actually hosted at the URL 
	in the 'Location:' field but don't update the 
	URL line displayed to the URL as the URL you 
	requested is really the official URL its just that
	for the moment we are keeping it over at the
	value in the Location field. Feel free to cache 
	that new URL and associate it with the URL 
	you requested until the 'Expires:' date/time 
	at which point you should re-request."

Essentially this would be like a 302 but where the temporary redirection is
not made transparent to users.

---

From: Travis Snoozy <[email-masked]>
Date: Wed, 7 Mar 2007 22:59:20 -0800

> If TCP/IP can't do this jow does SIP do it?  

By doing what amounts to a redirect. "Hey, Mr. Central Authority, I
want to talk to [email-masked]" "Well, he's at 10.0.0.2 right now"
"Great; I'll go call him there there!" Think dynamic DNS (or, more
directly, IP phones and IMs). You log on with a central server, and it
registers that you're online and what IP you have. Folks who want to
call/IM you get your presence info and communication (IP) address from
the server, either directly or through gateways. There is no
transparency, as far as the client *programmer* goes, of who the actual
sender/receiver of messages is (it is arguably transparent to the
actual end-user, but that's because the *client program* makes it
transparent). You perform a lookup, find the endpoint, and then call it
directly.

[http://en.wikipedia.org/wiki/Session_Initiation_Protocol]

> Essentially this would be like a 302 but where the temporary
> redirection is not made transparent to users. 
> 

See also: Persistent URLs (PURL) [http://www.purl.org/]

So, in other words, you're asking that user agents be forced to report
the original request URL, and not the redirected URL, to the user. That
seems like a presentational issue; at best, you might get a "SHOULD"
level requirement out of it. In practice, though, redirects seem to do
a pretty good job as it is. As it stands, many redirects are cacheable.

-- 
Travis

---

From: "Mike Schinkel" <[email-masked]>
Date: Thu, 8 Mar 2007 02:30:51 -0500

> So, in other words, you're asking that user agents be
> forced to report the original request URL, and not the
> redirected URL, to the user. That seems like a
> presentational issue; at best, you might get a "SHOULD"
> level requirement out of it. 

No, "SHOULD" isn't strong enough. I'm asking for an alternate "MUST" because
people bookmark the location returned which defeats the purpose,
*especially* now with the explosion of social media.  My point is: 

	If the URI authority wants to deem the 
	published URL instead of the serving 
	URL to be the canoncial URL, it should 
	be given the tools it needs to do so.

Clearly my proposal won't work on existing clients but what I'd like to see
is that if the client understands HTTP/1.2 [1] then it MUST display the
canonical URL but if it doesn't and only supports HTTP/1.1 then obviously it
is okay to behave as it currently does today.  OTOH, why not change the
rules changes for 302, assuming it wouldn't break anything (would it?) After
all, if it is a temporary redirect why should the temporary URL be displayed
by the client at all?

> In practice, though, redirects seem to do a pretty good
> job as it is. As it stands, many redirects are cacheable.
 
Actually, they do a horrible job. Have you ever noticed how many broken
links there are on the web?   (Yes, I know there is a logical disconnect in
my statement but having "HTTP Request Forwarding" that doesn't obscure the
original URL would empower URL virtualization as a solution for minimizing a
significant portion of broken links. Having the requirement for large static
content (images, video, etc.) to go through a proxy makes URL virtualization
it a non-option, but if the heavy content can be handled as I propose, it
opens a lot of potential doors for new techniques to solve nagging
problems.)

BTW, one of my favorite examples related to the broken URLs problem is a
post from June 2003 entitled "Future Proofing Movable Type URLs" [2]. It has
121 comments and/or trackbacks. Of the links in those comments and
trackbacks, OVER HALF no longer resolve! You couldn't get a more biased
sample of people who should know better -- people commented on a blog post
about future-proofing URLs -- yet over half haven't maintained those links
less than 4 years later.  I'm sure I'll be it's costing untold millions in
lost productivity and it causes important people to distrust the reliability
fo the web, yet nobody's really paying any attention to it.  I'd personally
really like to work on this problem. Getting HTTP Request Forwarding would
be a first step.

[1] I'm using "HTTP/1.2" as a euphamism for this newer version that supports
my proposal as compared to the existing HTTP/1.1
[2] http://mar.anomy.net/entry/2003/06/22/17.15.00/