Subject: Basic Authentication

From: Denero Watz <[email-masked]>
Date: Thu, 2 Oct 2003 12:08:52 -0400 (EDT)

Hello
   I am a newbie to HTTP and writing an http client
application. I need to authenticate to a server which
is protected by basic authentication. But to connect
to the original server I need to connect to a proxy
which is also protected by basic authentication.

What I need to do here is to send the base-64 encoded
authentication header as part of the request. But
since the this has to be passed at two levels, can I
pass two values for the header at the same time? one
for the proxy and the other for the actual server?
Otherwise I will get the challenge back from one of
these servers right?

I also wanted to know how valid is this scenario.

Thanks for any help,
dw

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 2 Oct 2003 13:50:32 -0600 (MDT)

On Thu, 2 Oct 2003, Denero Watz wrote:

>    I am a newbie to HTTP and writing an http client application. I
> need to authenticate to a server which is protected by basic
> authentication. But to connect to the original server I need to
> connect to a proxy which is also protected by basic authentication.

Try using Proxy-Authorization header for proxy authnetication and
Authorization header for the origin server authentication. Please see
RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication
for details: http://www.faqs.org/rfcs/rfc2617.html

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

---

From: Denero Watz <[email-masked]>
Date: Fri, 3 Oct 2003 05:06:36 -0700 (PDT)

Ok, 
but is passing two values for an Authorization header
supported?

--- Alex Rousskov <[email-masked]>

---

From: David Morris <[email-masked]>
Date: Fri, 3 Oct 2003 05:52:17 -0700 (PDT)

No, that is why there are different headers.

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 3 Oct 2003 08:49:12 -0600 (MDT)

On Fri, 3 Oct 2003, Denero Watz wrote:

> but is passing two values for an Authorization header supported?

Yes and no. Please read RFC 2616. An Authorization header is defined
using a #list construct and, hence, may contain multiple
header-fields. However, as David Morris already pointed out,
Authorization value(s) are for origin server authorization only, not
for the proxy authorization. Furthermore, I do not know how many
origin servers are compliant enough to look at multiple Authorization
values.

Forward proxies will not interpret the contents of the Authorization
header field, regardless of the number of values it contains. Forward
proxies look at Proxy-Authorization only.

HTH,

Alex.

> --- Alex Rousskov <[email-masked]> wrote:
> >
> > >    I am a newbie to HTTP and writing an http client application.
> > > I need to authenticate to a server which is protected by basic
> > Authorization header for the origin server authentication. Please
> > see RFC 2617 - HTTP Authentication: Basic and Digest Access
> > Authentication for details: http://www.faqs.org/rfcs/rfc2617.html
> >
> > Alex.

---

From: "John C. Mallery" <[email-masked]>
Date: Sun, 12 Oct 2003 23:36:46 -0400

I'd like to here what people think about the behavior of the current Apache reverse proxy, which rewrites the host header and adds the three x-forwarded-* headers.

What is the status of these x-forwarded-* headers?

Are there some specs to which implementations should adhere, or is this an Apache ideosyncracy
(bug)?

------------
Client Headers for 127.0.0.1 (HTTP/1.1)

:HOST =>  "127.0.0.1" 8000
:ACCEPT => (:* :*)
:ACCEPT-LANGUAGE => (:EN-US . 1) (:JA . 0.33) (:EN . 0.67)
:IF-MODIFIED-SINCE => 3187296000
:USER-AGENT => "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5"
:X-FORWARDED-FOR => "10.1.1.3"
:X-FORWARDED-HOST => "my.host.com:443"
:X-FORWARDED-SERVER => "localhost.localdomain"
:CONNECTION => :CLOSE

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 12 Oct 2003 22:58:48 -0700

They're X- headers; unofficial, albeit oft-used by reverse proxies (aka 
surrogates, gateways, etc.). X-Forwarded-For is quite common; 
X-Forwarded-Host and -Server are, I assume, to account for multiple 
virtual domains and/or multiple gateways in a farm.

As to its behaviour, everything that happens between a gateway and the 
upstream server is between those parties, more or less. These headers 
are pretty straightforward (although there are some potential security 
issues), but there are other issues brought about by using a HTTP 
gateway that's based on proxy software; e.g., those highlighted in
   http://www.research.att.com/~edith/Papers/HTML/usits01/

Cheers,

On Sunday, October 12, 2003, at 08:36  PM, John C. Mallery wrote:

>
> I'd like to here what people think about the behavior of the current 
> Apache reverse proxy, which rewrites the host header and adds the 
> three x-forwarded-* headers.
>
> :USER-AGENT => "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) 
> AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5"

---

From: "John C. Mallery" <[email-masked]>
Date: Wed, 15 Oct 2003 14:44:37 -0400

So, what happens if there is more than one reverse proxy in the chain?

X-Forwarded-For looks like the ip number of the reverse proxy.

X-Forwarded-server looks like the  virtual host (potentially), as you suggest.

What is not clear to me is why Apache can't just pass through the HOST header as
received and use the VIA header to convey the reverse proxy information to the
upstream server.

Why is a reverse proxy any  different than a forward proxy? Shouldn't the
VIA header do the job? Do we really need to differentiate the IP number from
the server domain? Shouldn't the later suffice?

At 22:58 -0700 10/12/03, Mark Nottingham wrote:
>They're X- headers; unofficial, albeit oft-used by reverse proxies (aka surrogates, gateways, etc.). X-Forwarded-For is quite common; X-Forwarded-Host and -Server are, I assume, to account for multiple virtual domains and/or multiple gateways in a farm.
>
>As to its behaviour, everything that happens between a gateway and the upstream server is between those parties, more or less. These headers are pretty straightforward (although there are some potential security issues), but there are other issues brought about by using a HTTP gateway that's based on proxy software; e.g., those highlighted in

---

From: Peter Watkins <[email-masked]>
Date: Wed, 15 Oct 2003 15:20:00 -0400

> the server domain? Shouldn't the later suffice?

These sound more like Apache/implementation questions than IETF/HTTP 
spec questions. Why does Apache, from your research, apparently send a 
different Host header? I could speculate[0] but I'm not sure this is an 
appropriate forum for discussing this particular behavior.

-Peter

[0] With the ProxyPass mechanism, the downstream server (the one that 
the end-user's client software connects to) is essentially 
*masquerading* -- very different from acting as an HTTP protocol proxy.

Let's say you configure the Apache httpd with
   ServerName yahoo.example.com
   ProxyPass /yahoomail/ http://mail.yahoo.com/
   ProxyPassReverse /yahoomail/ http://mail.yahoo.com/
Clients will send a Host header with content "yahoo.example.com" to the 
downstream/masquerading server. Now down/masq Apache will make an HTTP 
request to upstream mail.yahoo.com. It would not make sense for the 
down/masq Apache httpd on yahoo.example.com to pass along the Host 
header with the initial value ("yahoo.example.com") to upstream 
mail.yahoo.com, as the upstream server likely only accepts requests 
within the yahoo.com domain. Request a URI within "yahoo.example.com", 
and mail.yahoo.com is likely to give an error message (or, depending on 
the HTTP server software it uses, it might return HTML for a different 
site on the same IP address, e.g. content from "my.yahoo.com"). 
mail.yahoo.com is likely to only give reliably correct documents when it 
sees a Host header whose value it recognizes as one it's responsible for.

As for the X- headers, I'd *guess* that it is expected that the upstream 
server and downstream server will have some sort of relationship, and 
Apache is passing along the original client information in X- headers so 
that the info is available to the upstream server. Since Apache httpd's 
ProxyPass is a *masquerading* setup and not an implementation of a 
HTTP-compliant proxy server, X- headers were the only way for Apache to 
pass that info to the upstream server.

If that doesn't make sense (and it well might not; I'm not an Apache 
proxypass developer), I think you might want to follow up with an 
appropriate Apache mailing list.

---

From: "John C. Mallery" <[email-masked]>
Date: Wed, 15 Oct 2003 17:18:55 -0400

At 15:20 -0400 10/15/03, Peter Watkins wrote:
>These sound more like Apache/implementation questions than IETF/HTTP spec questions. Why does Apache, from your research, apparently send a different Host header? I could speculate[0] but I'm not sure this is an appropriate forum for discussing this particular behavior.

Hi Peter,

Actually this is more like a HTTP WG issue because the area of reverse proxies is
a dark corner in the standards, where interoperability can be problematic.

Here, we have one example implementation. But, I note that if the reverse proxy is performing
SSL encapsulation for the upstream server, the set of headers provided to the upstream server
is insufficient for it to realize that https URLs should be generated for any redirects to
urls serves through that gateway.

It would seem that lack of guidance from standards is leading to problems.

---

From: Peter Watkins <[email-masked]>
Date: Fri, 17 Oct 2003 10:35:10 -0400

> a dark corner in the standards, where interoperability can be problematic.

As long as the "downstream"/public-facing server talks HTTP to the
client, I don't care if it's communicating with the  backend/"upstream" 
server using HTTP, uucp, RPC, or RFC 1149 for that matter -- and I don't 
think the end users do, either. OK, maybe not RFC 1149. But if there's a 
business relationship between the downstream and upstream server, 
they'll work something out.

If there's not a business relationship, then the downstream server 
should issue an HTTP redirect to the client and be done with it.

Standards like HTTP exist to provide interoperability to disparate, 
unrelated systems on broad, often public, networks. That's generally not 
the case between downstream/upstream servers in an HTTP masquerading setup.

Well, that's my opinion. I'll back off and let you make your case to 
others. What I'd suggest: 1) suggest a "solution" 2) give more 
illustrations of the "problem" that don't involve Apache's ProxyPass 
implementation. I honestly can't tell if you have a general complaint 
(and, if so, how a public standard would address what I imagine your 
desire to be without facilitating something like content 
theft/misrepresentation) or a problem with Apache's software (maybe 
you're trying to do something that would be better served with other 
products [Squid? Inktomi Traffic Edge?]).

Cheers,

-Peter