Hi,

I was reading through the man pages and was trying to figure out the best 
way to define a virtual host in Pound.  The was I see it, I have 2 options:
1) Specify a URL pattern in my Service
2) Specify a HeadRequire Host: pattern in my Service

Ex:
Service
    URL    ".*//demo.domain.com.*"
End

or

Service
    HeadRequire    "Host:demo.domain.com.*"
End

Is there an advantage of using one vs the other?  Or should I use both? 
What advantage, if any, does the URL give over the HeadRequire instruction?

Thanks,

Eric

Hi,

The host is not present in the URL in HTTP (in this context at least [...]

Hi Jacques,

I'm not sure I understand what you mean by "The host is not present in the 
URL in HTTP".  Can you please elaborate?

If a client tries to connect to 
http(s)://www.domain.com/mysite/somepage.html, would the the URL not match 
to ^http(s)?://www\.domain\.com/.* ?
Would that not be equivalent of matching to header ^Host:\s*www\.domain\.com 
?

Am I misunderstadning something obvious?

Thanks,

Eric


"Jacques Caron" <jc(at)oxado.com> wrote in 
message news:MailBoxer.1284.1256090084.0.pound(at)apsis.ch...[...][...][...]

El Miércoles, 21 de Octubre de 2009, Jacques Caron escribió:[...]

Is it case sensitive? what about a valid header:
  host: www.example.tld
?
Would it match?

Regards.
[...]

The HTTP protocol works like so:

1) Connect to endpoint, using SSL if necessary. (Note we haven't sent  
any text or commands yet...)
2) Send request
GET /mysite/somepage.html HTTP/1.0
Host: www.domain.com



Connecting to the server is done by the browser...  It extracts the  
host and port for connection purposes.

Also note that the Host header is optional....  Browsers put it in but  
requests could come through without a host header. ( which is why  
apache has directives that work with namevirtualhosts to handle the  
"default" case)

Bottom line is, pound's URL matches the string after the GET, which  
does not have the host or protocol.

The only time you'd have a full protocol, host and port in the URL is  
if you were talking to a proxy server.  The proxy server would forward  
your request to the URL specified, but it would do so like a browser -  
it would turn it into a request like the above when it connected to  
the destination.

Joe Gooch
K12 Systems Inc


On Oct 20, 2009, at 11:55 PM, "Eric B." <ebenze(at)hotmail.com> wrote:
[...][...]
>>> Hi,
>>>
>>> I was reading through the man pages and was trying to figure out  
>>> the best
>>> way to define a virtual host in Pound.  The was I see it, I have 2
>>> options:
>>> 1) Specify a URL pattern in my Service
>>> 2) Specify a HeadRequire Host: pattern in my Service
>>>
>>> Ex:
>>> Service
>>>    URL    ".*//demo.domain.com.*"
>>> End
>>>
>>> or
>>>
>>> Service
>>>    HeadRequire    "Host:demo.domain.com.*"
>>> End
>>>
>>> Is there an advantage of using one vs the other?  Or should I use 

>>> both?
>>> What advantage, if any, does the URL give over the HeadRequire
>>> instruction?
>>>
>>> Thanks,
>>>
>>> Eric
>>>
>>>
>>>
>>>
>>> --
>>> To unsubscribe send an email with subject unsubscribe to
>>> pound(at)apsis.ch.
>>> Please contact roseg(at)apsis.ch for questions.[...][...]

At 12:56 21/10/2009, Joe Gooch wrote:[...]

Host: is mandatory in HTTP/1.1. But in HTTP/1.0 there might be cases 
where no Host: header is sent (the Host: header did not exist in the 
HTTP/1.0 spec, but that was more than 10 years ago), and obviously 
nothing prevents someone from sending a non-conforming request.

Jacques.

Thanks for the clarification guys.  Followup question though.  Does that 
imply that there is no reliable way to use Virtual Hosting for HTTP/1.0 
clients (although probably pretty much non-existant these days)?

Thanks,

Eric


"Jacques Caron" <jc(at)oxado.com> wrote in 
message news:MailBoxer.1289.1256127569.22.pound(at)apsis.ch...[...][...][...]

From http://httpd.apache.org/docs/2.2/vhosts/name-based.html:
Name-based virtual hosting is usually simpler, since you need only configure
your DNS server to map each hostname to the correct IP address and then
configure the Apache HTTP Server to recognize the different hostnames.
Name-based virtual hosting also eases the demand for scarce IP addresses.
Therefore you should use name-based virtual hosting unless there is a specific
reason to choose IP-based virtual hosting. Some reasons why you might consider
using IP-based virtual hosting:

    * Some ancient clients are not compatible with name-based virtual hosting.
For name-based virtual hosting to work, the client must send the HTTP Host
header. This is required by HTTP/1.1, and is implemented by all modern HTTP/1.0
browsers as an extension. If you need to support obsolete clients and still use
name-based virtual hosting, a possible technique is discussed at the end of
this document.
    * Name-based virtual hosting cannot be used with SSL secure servers because
of the nature of the SSL protocol.
    * Some operating systems and network equipment implement bandwidth
management techniques that cannot differentiate between hosts unless they are
on separate IP addresses.




I'm not sure what counts as "obsolete clients".  I haven't seen a browser in
quite some time that *doesn't* send a host header.  So that's your only
concern.

You should probably have a catchall Service that doesn't have a headrequire
that will handle the HTTP/1.0 without host header case.

You'll notice in my last email that SSL negotiation happens before the browser
says anything.  That's why SSL name-based virtual hosts do not work, unless you
have an appropriate wildcard cert and all hostnames belong to the same parent
domain. (for instance, support.mydomain.tld, help.mydomain.tld, would work with
a cert for *.mydomain.tld)  The server has to present a certificate before the
browser can send the Host: header.


Joe Gooch
K12 Systems Inc
 
[...]