Re: HTTP Request Forwarding?

On Thu, 8 Mar 2007 00:52:50 -0500, "Mike Schinkel"
<> 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" "Well, he's at 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


> 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) []

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.


Received on Thursday, 8 March 2007 06:59:43 UTC