On 08/09/2010 03:27 PM, Daniel Stenberg wrote:
> On Mon, 9 Aug 2010, Matthieu Speder wrote:
>
> Please don't top-post!
>
>> Imagine one https server with a single dns name (app.haxx.se) and you
>> are
>> not allowed to create a second entry.
>
> So you have a server that you can control and access the SNI field
> with, but you can't add a second entry in the DNS for the host? It
> seems awfully kludgey to then just invent a host name in the SNI to
> get a specific meaning like that.
>
> It struck me that an arguably nicer way to handle this would be to use
> the host name provided in a custom Host: header - something we
> actually already do for cookies.
>
One might argue that setting a Host header should not be an option for
the user, it should be derived from the URL.

At least, linking Host: to the SNI is correct according to the RFC
So if such a name is set it should go both to SNI and Host:

There may be an issue with proxies. The CONNECT would not have
the same hostname as the SNI. Some firewalls might filter this.

There is another possibility in the server: Like it is done in apache,
based on the directory portion of the url, one initiates a renego,
this is a slight performance pb and one has to correctly buffer
the request.

In the described case the goal is not a different
server cert but rather not to request a client cert.
Furthermore, a server can always request a cert, and then accept
a response without it and require basic auth then. One does
not need to distinguish very early.
If there is no matching client cert, a normal browser just doesn't
respond with one, one tolerates that and the server
asks for basic auth.

Peter

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-08-09