Re: HTTP Request Forwarding?

On Thu, 8 Mar 2007 00:52:50 -0500, "Mike Schinkel"
<mikeschinkel@gmail.com> wrote:

> 
> 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?  

By doing what amounts to a redirect. "Hey, Mr. Central Authority, I
want to talk to foo@example.org" "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]

> 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. 
> 

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