Understanding http proxies

[Olive]

I am trying to understand how to build an http proxy server in python,
and I have found the following example:

http://www.oki-osk.jp/esc/python/proxy/

But I do not have found an exact description of what exactly a proxy
server is suppose to do (all references gice only the basic principe of
proxy that I know). In the following model

Client <-> Proxy <-> Server

it seems when I read the code above that the proxy acts mostly as an
orinary server with respect to the client except that it is supposed to
receive the full URL instead of just the path. Am I right? Is there any
documentation on what an http proxy is supposed to implement.

Olive

[Chris Angelico]

On Sun, Oct 14, 2012 at 5:43 AM, Olive <di...@bigfoot.com> wrote:
> it seems when I read the code above that the proxy acts mostly as an
> orinary server with respect to the client except that it is supposed to
> receive the full URL instead of just the path. Am I right? Is there any
> documentation on what an http proxy is supposed to implement.

The easiest way to test this is to knock together a quick little
server, set your browser to use localhost as a proxy, and see what
requests you get.

You're correct as regards most requests, but HTTPS is more
complicated. All your proxy will see is a CONNECT request; you have to
accept or deny on the basis of address alone, you don't get the whole
URL (for obvious reasons). But that aside, yes, you'll normally get a
request that looks pretty similar to what the origin server would get.

ahh, happy memories of MUDding through a local proxy that permitted
CONNECT on more ports than 443... and even happier memories of getting
port 23 opened to direct access, hehe...

ChrisA

[Tim Roberts]

Olive <di...@bigfoot.com> wrote:
>
>it seems when I read the code above that the proxy acts mostly as an
>orinary server with respect to the client except that it is supposed to
>receive the full URL instead of just the path. Am I right? Is there any
>documentation on what an http proxy is supposed to implement.

Consider the ways HTTP could have been implemented. Say we have a request
to get http://www.bigsite.com/pictures/index.html .

One way HTTP could have been implemented is by sending this request to the
server at www.bigsite.com:

GET /pictures/index.html HTTP/1.0

If that were how HTTP were done, you could not implement a proxy, because
there isn't enough information for any intermediates to know where the
request had to end up.

Instead, http looks like this:

GET /pictures/index.html HTTP/1.1
Host: www.bigsite.com

Now, even if this is sent to someone who is not "www.bigsite.com", that
receipient can tell exactly who is supposed to get the message.

So, a web proxy receives requests intended for other sites, and forwards
them on, possibly after restricting or modifying them. That's it.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Cameron Simpson]

As mentioned elsewhere, in HTTP 1.0 you get a full URL in the opening
line.

In HTTP 1.1 you get the path component in the opening line and the host
part in the Host: header of the request.

Have a read of RFC2616 (which defines HTTP 1.0):

http://tools.ietf.org/html/rfc2616

It has sections on proxies, too, outlining which they must do beyond
what a plain HTTP server must do (not much, but a few things, and there
are proxy-specific authentication fields available too):

Proxy Servers
http://tools.ietf.org/html/rfc2616#section-8.1.3

Proxy Authenticate
http://tools.ietf.org/html/rfc2616#section-14.33

Cheers,
--
Cameron Simpson <c...@zip.com.au>

There's two kinds of climbers...smart ones, and dead ones. - Don Whillans

[Olive]

Thank you for all yours answers. There are very usefull!

Olive