Comments on: Proposing HTTP Request Forwarding http://blog.welldesignedurls.org/2007/03/08/http-request-forwarding/ Advocating User-Centered URL Design Fri, 03 Jun 2011 05:01:36 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: chary http://blog.welldesignedurls.org/2007/03/08/http-request-forwarding/#comment-90039 chary Fri, 23 May 2008 09:05:03 +0000 http://blog.welldesignedurls.org/2007/03/08/http-request-forwarding/#comment-90039 http://wiki.welldesignedurls.org/URL_Interfaces Parse error: syntax error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or '}' in /home/welldesi/public_html/wiki/includes/Exception.php on line 114 http://wiki.welldesignedurls.org/URL_Interfaces

Parse error: syntax error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or ‘}’ in /home/welldesi/public_html/wiki/includes/Exception.php on line 114

]]> By: Tom Barta http://blog.welldesignedurls.org/2007/03/08/http-request-forwarding/#comment-8258 Tom Barta Tue, 01 May 2007 14:53:48 +0000 http://blog.welldesignedurls.org/2007/03/08/http-request-forwarding/#comment-8258 The problem with doing something like this is the underlying TCP mechanisms. When client A establishes a connection with server B, there is an open TCP connection. A can be behind a firewall or a NAT, and B's response will come in fine because the connection was already established. C, on the other hand, cannot directly send content to A (at least, not reliably). At present, it's up to A to re-request the content from C, because an HTTP response must be followed by a request in order to work with the current model of the Internet (unless everyone wants to switch to IPv6 right now). Because HTTP is client-server and not peer-peer, there needs to be a URL at C to access the content. Unless you have a rewriting proxy sitting somewhere in the middle, you'll always have to deal with secondary sub-par URLs being visible to an HTTP client. The problem with doing something like this is the underlying TCP mechanisms. When client A establishes a connection with server B, there is an open TCP connection. A can be behind a firewall or a NAT, and B’s response will come in fine because the connection was already established.

C, on the other hand, cannot directly send content to A (at least, not reliably). At present, it’s up to A to re-request the content from C, because an HTTP response must be followed by a request in order to work with the current model of the Internet (unless everyone wants to switch to IPv6 right now).

Because HTTP is client-server and not peer-peer, there needs to be a URL at C to access the content. Unless you have a rewriting proxy sitting somewhere in the middle, you’ll always have to deal with secondary sub-par URLs being visible to an HTTP client.

]]> By: Glyph Lefkowitz http://blog.welldesignedurls.org/2007/03/08/http-request-forwarding/#comment-2780 Glyph Lefkowitz Sat, 17 Mar 2007 01:50:59 +0000 http://blog.welldesignedurls.org/2007/03/08/http-request-forwarding/#comment-2780 I notice that you did not mention redirects at all in this post. What's the difference between this, and server "B" issuing a redirect response for splash.png? In the image-hosting case, the user will never see an URL that points to the image-hosting service. The URLs in the document will point to "B", and the browser never puts the URL for an "img src" into the location bar. I notice that you did not mention redirects at all in this post.

What’s the difference between this, and server “B” issuing a redirect response for splash.png? In the image-hosting case, the user will never see an URL that points to the image-hosting service. The URLs in the document will point to “B”, and the browser never puts the URL for an “img src” into the location bar.

]]>