Subject: Response to HTTP2 expresions of interest

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Jul 2012 13:09:50 -0400

This is a personal expression of interest in HTTP 2.0 which may or may
not be the opinion of my employer.

Although my recent interest has been focused on security, I have been
involved in development of HTTP since 1992. Some observations.

1) Deployability

Defining a new capability is not the hard part. We have had great
schemes for multiplexing and security for decades. The devil is in the
deployment. I rather liked Henryk's scheme and Rohit's and really
liked a few of mine.

Any new capability has to find a niche that can attract some self
supporting early adopters. Deploying new capabilities in browsers is
hard because everyone has to think about the legacy. Web services is a
much easier area to get traction as there are new web services being
developed every week and the people deploying them can and will choose
the platforms that best meet their needs.

So I would strongly urge people to think about solving at least some
of the problems of the Web Services world as that is the best bet we
have to find a killer app for HTTP 2.0. If the code is used for web
services it will get pulled along into the browser chain much faster.

2) Code budget

Before going anywhere, ask how many bytes the browsers might commit to
these proposals. I would be very surprised if they would allow more
than 100Kb for the whole of HTTP/2.0.

Ergo anyone proposing integrating their favorite API with a 500Kb dll
is pushing a total non-starter. In fact I think that any scheme that
cannot be implemented in fifty or so pages of self-contained code is a
non-starter.

3) Boat Anchors

This is not an opportunity for people to get the HTTP world to pull
through deployment of their standard that they have been trying to get
traction with for 20 years. This is called getting someone else to
carry your boat anchor. I have seen the strategy tried time and again
by people who didn't think through the deployment issue.

GSS-API was considered in 1995 and found to be too big, slow and
difficult to understand. I don't think it should be reconsidered
unless it has been drastically reduced in size since. I believe the
opposite to be the case.

4) Frameworks

HTTP is a framework and frameworks should not be built on other frameworks.

Making Kerberos or NTLM or SAML or whatever work better with HTTP is
fine provided that the framework specific code is no more than a
header or two and preferably even less.

Making support for Kerberos, SAML, or whatever boat anchor you want to
name a requirement of HTTP 2.0 is a non starter.

And yes, I am talking about GSS-API again.

5) Complexity

Complexity is the enemy of security. TLS and GSSAPI and IPSEC all have
far too many moving parts to be 100% confident about the security.

5a) The TLS-HTTP gap

Now as far as HTTP is concerned, headers have security implications
and so HTTP is not going to be acceptably secure without either
transport layer or packet layer security. Since IPSEC never got its
key exchange act together that leaves TLS as the only game in town for
that.

TLS itself is solid but when you try to work out the interaction
between HTTP and TLS, well it just isn't possible to be 100% confident
that nothing falls through the cracks.

My conclusion is that going forward we should plan on the basis of
expecting cryptographic security at the HTTP layer AND the Transport
layer and expect them to provide different controls.

In 1995 even symmetric cryptography was expensive and the idea of
using more than one layer when you didn't need to was quite an
overhead. Modern machines are more than capable of supporting belt and
braces security.

5b) The HTTP-HTML gap

Another place that security breaks down is in the interface between
HTTP and HTML. In particular running passwords en-clair is really a
HTML issue rather than a HTTP issue.

6) Authentication

I have been involved in many authentication schemes over the years. I
don't think any of them is 100% right. But I would urge HTTP 2.0 to
NOT use SAML or OAUTH authentication as the basis for HTTP/2.0

The reason for this is that the main design constrain in SAML, OAUTH,
OPenID or any other scheme you name was how to work around the legacy
browser and server infrastructure. HTTP 2.0 can help us remove.

I think one of the reasons for confusion is that there are actually
three distinct processes that are referred to as 'authentication'.
Another is that the authentication schemes on offer tended to punt on
the idea of a federated identifier space because various commercial
interests backing the authentication schemes to date all rather
fancied themselves as being in charge of it.

This is the Internet so we use DNS as the federated naming repository.
Holders of DNS names will then issue accounts under them. Ergo an
Internet account name will be normalized as [email-masked] end of
story (ok give it a urn, acct:[email-masked]). If people want to
do XRI or OSI or whatever, that is outside core HTTP. The concept of
vanity crypto is well understood in the security area. Vanity
namespaces deserve the same derision.

In this particular scheme a local, non federated name is simply an
account with an implicit domain component of localhost, .local or
whatever. If we want to integrate Windows domain accounts into this
scheme we would use either the DNS name of the domain controller as
the account name or reserve _windows.local or the like for the
purpose.

The processes I see are:

1) Validation: Is the holder of account name 'x' the authoritative
holder of that account name

    e.g. to Validate [email-masked]' we might:
        * Send an email callback challenge
        * Check a service such as OAUTH or OpenID supported by example.com
        * Do a PKI protocol based on a CA issued certificate issued to
 [email-masked]'
        * Do nothing at all
        * other TBS

So in this scheme the only identifiers are implicitly federated as
they all contain domain names. We address the real world corner cases
by accepting that there are degrees of validation ranging from strong
(a statement coming from the authoritative name holder) to
non-existent (don't check the name at all) and by allowing for the use
of the parts of the federated DNS namespace that do not guarantee a
unique authoritative nameholder.

2) Initial-Authentication: A user authenticates themselves to a
destination on a particular device.

This is what is generally considered as 'authentication' today. To log
in to battle.net I provide my username and password. Then I can go
beat up daemons.

Now one of the reasons passwords are so hard to get rid of is that
they are a very simple and convenient means of enabling account
portability from one device to another. A separate hardware token like
the OTP token battle.net sells or a USB key is nowhere near as
convenient as just a password. And as for the idea of moving
certificates from one machine to another...

This is currently done at the HTML layer and not in HTTP.

If we are going to replace passwords we have to provide a scheme that
is at least as convenient as passwords. I am not getting a battle.net
token and I was one of the people who wrote OATH. The only approach
that is as convenient for the user is to leverage some cloud based
service.

3) Re-Authentication: Having performed an initial authentication, a
stored credential is used to authenticate additional transactions.

This is a part that is currently performed by HTTP albeit using
cookies which provide a weak cryptographic binding to the channel and
give rise to all sorts of privacy horrors.

A cryptographic scheme would mean the client a per-session ticket (50
bytes), secret key and binding parameters and the client and server
performing some form of simple mutual authentication on each
transaction. This is actually quite easy and fast if you use symmetric
key.

If you look at the problems involved you will see that there is a lot
of real-world variation in approaches to the first, rather less on the
second and practically none on the third.

We can define a very simple mechanism for re-authentication in HTTP
2/0 that can then be used by any of the authentication frameworks that
care to use it. That approach can even be made to support features
like global sign-off in a framework neutral way.

There may be value to addressing at least some parts of initial
authentication in HTTP 2.0 but this needs to be addressed with a
careful eye on the code budget. I will return to that in another post.
There are quite a few moving parts. There does need to be a bridge
from the initial authentication to the re-authentication and none of
the legacy mechanisms is going to be satisfactory as they were all
constrained by HTTP 1.1. the justification for redoing this in HTTP
2.0 is that we have the opportunity to put the crypto where it will do
us the most good.

The first part, validation should be left to site policy and be out of scope.

-- 
Website: http://hallambaker.com/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 13 Jul 2012 17:37:23 +0000

In message <[email-masked]>
, Phillip Hallam-Baker writes:

>transport layer or packet layer security. 

I disagree.

What HTTP lacks is a clear distinction between "envelope" and "body"
the way SMTP and NNTP have it.

HTTP/2.0 would enable a lot more sites to run with cryptographic
security, if there were an unprotected envelope for load-balancers
to act on.

I also think it should be possible to mix protected and unprotected
requests on the same TCP session.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Tim Bray <[email-masked]>
Date: Fri, 13 Jul 2012 10:41:44 -0700

How much information needs to be in the unprotected envelope?  Because one
of the benefits of transport-level security is that a snooper, for example
a government tracking dissidents, knows little/nothing about my traffic
aside from the routing.  Not a rhetorical question.  -Tim

On Fri, Jul 13, 2012 at 10:37 AM, Poul-Henning Kamp <[email-masked]>wrote:

> In message <
> [email-masked]>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Jul 2012 13:42:10 -0400

OK HTTP is not going to be acceptably secure for the types of
application TLS is typically used today.

But that is still only 1% or so of traffic. that leaves quite a gap.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 13 Jul 2012 19:53:35 +0200

> requests on the same TCP session.

+1 on all these points !

Also, in some environments, the need for clear-text but signed exchanges
is common in order to avoid tampering and to ensure transported data is
safe. As amazing as it may seem, I first noticed this requirement in
banking environments. There are places like this where most of the
transported data has no direct user information but needs to be easy to
control and process. In all these situations, dealing with a clear-text
envelope is by far the best solution.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 13 Jul 2012 17:59:12 +0000

>aside from the routing.  Not a rhetorical question.  -Tim

And this is exactly about the routing.

The three fields that today should be part of the envelope is
"Host:", URI (Sans query part) and Session-Nonce.  (Since we don't
actually have a session-nonce, today people route on cookies.)

And like all other message transfer systems from snail-mail and
forward, the envelope need not give anything away, because what you
put on it only have to get the message to the right place, it doesn't
have to _be_ the message.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 13 Jul 2012 18:00:25 +0000

In message <CAMm+LwgQRnXsjvFkg42Tm3qZmY=M34-n1WM1W9V9oF-=[email-masked]>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 13 Jul 2012 18:02:05 +0000

>application TLS is typically used today.

(Sorry, email misfire there).

I think you're wrong about that.

TLS already today leaks a lot of information to an eavesdropper, and
adding a convenient routing-envelope will not increase that leakage
if it is done correctly, but it will make it a lot easier for HTTP
server side to implement and handle protected traffic at high
traffic densities.

---

From: James M Snell <[email-masked]>
Date: Fri, 13 Jul 2012 11:10:08 -0700

Definitely a tricky thing here because of the competing interests and
requirements at play. Transport-layer secure provides the necessary
protection against snoopers but makes the efficient routing and
handling of the communication via intermediaries far more difficult.
Given the revised framing allowed in SPDY, is conceivable that two
distinct layers of security can be utilized here... one protecting the
envelope and another protecting the data end to end. The question then
becomes: which information is part of the envelope and which is part
of the payload... the fact that intermediaries need to be able to
route based on request URI and cookies is what makes this question
difficult to answer.

Perhaps something along the following lines would work:

1. Allow for an additional set of control frames that allow for the
negotiation of keys for use with encrypted streams...
2. Once established, a SYN_STREAM can be sent in the clear containing
ONLY the information the sender is willing to share "in the clear"
with the intermediary. This may or may not include cookie and request
URI details. The intermediary can determine, based on what is shared,
whether it is capable of properly handling the request with the
information given. If it's not, it can refuse the stream. The
intermediary could also potentially send it's own control frame
indicating which information it requires in order to do it's job.
Either end can choose to accept or reject the stream based on the
stated requirements.
3. Assuming the stream is accepted, either end can choose to send
encrypted data frames interleaved with clear text data frames.
encrypted data frames would include the ID of the negotiated key.
4. A sender can choose to send an unencrypted data frame if the frame
contains information that it feels is ok for the intermediary to see
and operate on. At any time, if the intermediary feels it does not
have sufficient access to the data in the stream to do it's job, it
can reject the stream.
5. With this Transport Layer Security can continue to be used. At the
intermediary level, it would only need to deal with encryption at the
TLS level, while leaving it to the client and server to deal with the
stream-level encryption.

This definitely adds an additional layer of complexity to the whole
process but I think the benefits would be worth it. For one, done
properly, it would allow two endpoints to negotiate encryption of the
data on the fly based on individual requests, even when transport
layer security is not being used... and encrypted data could be sent
interleaved with non-encrypted data on the same connection... even
within the same stream...

- James

On Fri, Jul 13, 2012 at 10:41 AM, Tim Bray <[email-masked]> wrote:
> of the benefits of transport-level security is that a snooper, for example a
> government tracking dissidents, knows little/nothing about my traffic aside
> from the routing.  Not a rhetorical question.  -Tim
>
>
>> In message
>> <[email-masked]>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 13 Jul 2012 18:21:30 +0000

In message <[email-masked]>

>handling of the communication via intermediaries far more difficult.

I still don't agree.

The envelope is where you write who you want your adversary to think
you are communicating with.

This may or may not be who you actually are communicating with.

TLS communication today already have an envelope consisting of
IP# + TCP port numbers, and unless your adversary is totally
incompetent, he also has the DNS lookup that gave you that IP#.

QED: Putting the "Host:" in the HTTP envelope does not leak any
information your adversary doesn't already have or can guess.

Even if we stopped here, it would be a major benefit over TLS
in terms of enabling websites to roll out protection for their
customers.

To make it better, we need to add a session identifier, but today
we pretend HTTP is stateless so we don't have one (so people
hack it with cookies).

Finally, to do what people do today we would need to include the
URI, but that is by far the most troublesome of the three fields.

I belive, but it should be seriously investigated, that if we add
a session-concept to HTTP2, the envelope would just need to be Host:
+ session-nonce.

In difference from TLS, that would allow us to mix protected and
unprotected traffic on the same TCP connection, thus avoiding
the extra TCP for protection upgrade, and making life much
easier and efficient for proxies.

It also means that you do not need to put your certificate on
the HTTP router/load-balancer, but can put it on the specific
webservers which host the protected stuff.

SSL/TLS was a quick hack to protect HTTP, one of the far too
many quick hacks in HTTP world.  We should try to eliminate
them.

---

From: James M Snell <[email-masked]>
Date: Fri, 13 Jul 2012 11:36:03 -0700

Sounds like we're generally in agreement on most aspects then. I agree
that TLS would not be strictly necessary if we have effective
stream-level security, and I definitely agree that a session
identifier at the stream-level would be highly beneficial. In the
scheme I described, sending a SYN_STREAM with the host and session-id
ONLY, in clear-text, and then encrypting subsequent data frames on the
stream, including the request-uri in an encrypted HEADERS frame,
SHOULD provide for the overwhelming majority of cases. As I said, if a
particular intermediary needs to perform request-uri based routing and
the request-uri is not included in the SYN_STREAM, it has the option
of rejecting the stream, in which case the sender can choose it's next
course of action.

Like I said, it appears to me that we are in agreement but if I am
misreading it, please let me know :-)

- James

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 13 Jul 2012 18:40:51 +0000

In message <[email-masked]>
, James M Snell writes:

>Sounds like we're generally in agreement on most aspects then. 

I think we agree about the broad outline, and that's the important
thing for me :-)

---

From: Brian Pane <[email-masked]>
Date: Fri, 13 Jul 2012 12:26:49 -0700

On Friday, July 13, 2012, Poul-Henning Kamp wrote:

> In message <
> [email-masked]<javascript:;>
> >
> , Tim Bray writes:
>

>From the perspective of a load balancer, having just those three fields in
cleartext isn't sufficient. Sending a request to the proper upstream
destination may require information from Cookie, X-Forwarded-For, and more.

And because there's an overlap between the fields often needed for load
balancing and the fields that contain PII, trying to put the former in a
cleartext envelope Is a tricky proposition.

I'm not too concerned about load balancers having to decrypt messages,
though: SSL termination has been a key selling point for load balancers for
many years.

-Brian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 13 Jul 2012 19:50:43 +0000

>destination may require information from Cookie, X-Forwarded-For, and more.

(X-)F-F makes sense.

Cookies: not so, whenever people use cookies, they are working around
lack of session concept in HTTP.  HTTP/2.0 should fix that, so cookies
go away.

>though: SSL termination has been a key selling point for load balancers for

That's not the same as it being a good idea.

Hosting providers are often unable to deploy load-balancers and
DoS mitigation, exactly because it would require them to have all
their hosted clients certificates.

---

From: "HAYASHI, Tatsuya" <[email-masked]>
Date: Sat, 14 Jul 2012 05:36:21 +0900

Dear Poul-Henning,

(disclaimer, I am one of the authors of http-mutual authentication I-D.)
IHMO(not authors. only me.),
HTTP Authentication (ex. Digest) has the state that I can call a session.

I think that this becomes the materials of this discussion.
"HTTP router" is very well put.
I want to know how the HTTP Authentication is handled on it.

Do you have any opinion about this?

-- 
HAYASHI, Tatsuya
Lepidum Co. Ltd.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 13 Jul 2012 22:05:18 +0000

In message <[email-masked]>

>Do you have any opinion about this?

Not really at this point, but given a chance to think about it
I'm sure that both I and many others will have.

I my ideal world, we would start by spending some months deciding
what services HTTP/2.0 should actually provide, and try to find the
best, small, easy to understand set of primitives that do that.

That may be a good deal tricker than people think.

For instance the fact that several major web-commerce sites 
prominently display stuff like:

	Hello Poul-Henning (Not Poul-Henning ? Press Here)

clearly indicates how broken the current protection crap really is...

The protection issues are particularly thorny because many people
think they can enforce their political agendas using protocol design
and specifications, as exemplified in the "end-to-end privacy" wars.

The only thing you get if you try to do that, is that people will
make workarounds for the "banned" practices, such as wild-card
certificates for legally mandated interception, and cookies as
session-hacks and so on.

A much better strategy is to make these practices possible
and detectable, so that the users know when they are subject
to them.

If I should give a first cut on the protection primitives I would
expect from HTTP/2.0 it would be:

* Get other ends proffered proof of identity (aka: its certificate)

* Request privacy protected session/channel

* Identify first privacy endpoint
  Ie: do we have end to end privacy, and if not, who am the first
  entity I must trust ?
  Amongst perfectly valid and reasonable answers: 
	The corporate firewall.
	The prisons legal intercept.
	The countrys censorship institution.

But I am sure that there are people better than me to perform
that analysis, and I really wish the WG would engage some of
them, rather than rush headlong into protocol redesign...

---

From: Nico Williams <[email-masked]>
Date: Fri, 13 Jul 2012 17:40:02 -0500

> cannot be implemented in fifty or so pages of self-contained code is a
[...]
> unless it has been drastically reduced in size since. I believe the

Once more, with feeling: :) There's no need to use the GSS-API in
order to use GSS mechanisms.

The portion of GSS security mechanisms that a REST-GSS client would
have to implement can be quite minimized compared to a full
implementation.  For a mechanism like SCRAM the total size should be
quite small (especially if you don't count HMAC nor the hash function,
because those are probably to be shared with other parts of the client
application).  For a ZKPP it's probably a little bigger.  For a ZKPP
mechanism with federation support with the server doing all the
infrastructure messaging work the code should be about the same size.

*Kerberos* code is going to be huge, largely because of ASN.1/DER and
a much heavier crypto footprint (there's a number of ciphersuites).
But that's another story.  I'm not proposing Kerberos.  I'm proposing
that HTTP/2.0 auth be pluggable.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Jul 2012 23:48:58 +0100

> and detectable, so that the users know when they are subject

It *might* be a better strategy if there were a way
to do it that didn't trivially expose the client
to just about any bad actor, or else make the client
captive to some (possibly bad) actor.

I suspect that a lot of proposals along those lines
will come a cropper like that, e.g. because they
require a client to trust some unprotected signal
from the network or else they require all clients to
have some configured entity that they'll just
believe about all this stuff.

So that's just not easily solved. Perhaps even
beyond the state of the art in the general case.
But who knows. There are many smart folks involved
here. I'll not hold my breath though to be honest.

Having said that, the earlier discussion about
having some few bits of information (host and
a new session id) in an unencrypted but perhaps
signed'MAC'd envelope sounds like it might help
with a bunch of this. So at a high level that
does sound promising.

Though I guess not for the "corporate censor"
part. I dunno what can be done about that.

Anyway, interesting challenges ahead all right!

S.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 13 Jul 2012 22:55:01 +0000

In message <[email-masked]>, Stephen Farrell writes:

>So that's just not easily solved.

Absolutely not.

But I don't the pretending that it isn't an issue works out too
well either, as evidenced by the current cleanup of unwisely issued
certificates.

>part. I dunno what can be done about that.

Allowing you to send "GET https://...." to a proxy will go a long
way for quite a lot of these cases.

>Anyway, interesting challenges ahead all right!

Indeed, but only if the WG decides to actually do something about them.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 14 Jul 2012 00:04:14 +0100

> Indeed, but only if the WG decides to actually do something about them.

Well, the process of deciding has been interesting
already:-)

S.

---

From: Tim Bray <[email-masked]>
Date: Fri, 13 Jul 2012 20:21:03 -0700

> information your adversary doesn't already have or can guess.

That’s just not true.  There are lots of ways to get to a particular origin
server, and I would think that for a malicious person in the middle, the
Host header would be more interesting than the ostensible IP address.  On
the other hand, I do understand why a payload-oblivious load balancer would
need to see that header.  It is simply the case that we have two objectives
which are apparently in conflict. No, I don’t have a solution (or even a
strong opinion, yet, although I’m inclined to err on the side of protecting
user privacy at the expense of almost all else).  -Tim

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 14 Jul 2012 07:52:50 +0200

On Fri, Jul 13, 2012 at 08:21:03PM -0700, Tim Bray wrote:
> That?s just not true.  There are lots of ways to get to a particular origin
> which are apparently in conflict. No, I don?t have a solution (or even a
> strong opinion, yet, although I?m inclined to err on the side of protecting

Well, TLS offers SNI which also reveals the Host header in clear text, so
your extreme view of privacy doesn't seem to be shared as much wich even
these guys. Also, building a protocol fortress that prevents anyone from
implementing it in real life is an effective way of protecting user privacy
since the user won't have access to anything and thus won't reveal his
intents. Maybe some people would even consider that revealing they have
access to the internet affects their privacy so they need an invisible
connection... At one point a limit must be set, otherwise it becomes
totally non-sense. Host and IP are reasonably interchangeable, are used
for routing the protocol to its destination, and if someone doesn't want
to show what host he's going to, he'd better leave the net. And if even
the TLS guys accept this, then I think this is a much acceptable limit.

Regards,
Willy

---

From: "HAYASHI, Tatsuya" <[email-masked]>
Date: Sun, 15 Jul 2012 03:32:18 +0900

PHK's ideal world, I also share it.

However, it is not understood whether it is contained in the present
WG charter.
I still think that our goal is ambiguous.

To speak of extremes, we have a two targets.

1)
Efficiency is improved. and compatibility is maintained as much as possible.
2)
The ideal which deserves HTTP/2.0 and which can be used for 20 years
or more is aimed at.

These are not contrary.
We have to pursue the both as much as possible.
But, The semantics must not change.

I think that the name of HTTP/2.0 is making a goal difficultly.

I thinking...
ex) HTTP layer Session is necessity?
  If it is HTTP/1.1tris?
  If it is HTTP/1.2?
  and If it is HTTP/2.0?

We need to deepen an concrete discussion more.

--
HAYASHI, Tatsuya
Lepidum Co. Ltd.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 14 Jul 2012 17:00:58 -0400

If this is worth doing at all it is something that can be most easily
performed in a HTTP/2.0 context where the whole legacy question
becomes moot-ish

---

From: Mike Belshe <[email-masked]>
Date: Sat, 14 Jul 2012 15:00:53 -0700

I disagree with the claim that the current http charter is not designed for
the next 20 years. It is, and spdy is.

I have yet to see any proposals of something better or missing from the
current proposals. If there are better ideas, by all means raise them.
Please be detailed and offer proof where possible.

Mike

---

From: "HAYASHI, Tatsuya" <[email-masked]>
Date: Sun, 15 Jul 2012 08:02:03 +0900

Hummm.
I think that it is right.

Thanks.

--
HAYASHI, Tatsuya
Lepidum Co. Ltd.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 15 Jul 2012 10:15:31 +0200

On 2012-07-15 00:00, Mike Belshe wrote:
> I disagree with the claim that the current http charter is not designed
> for the next 20 years. It is, and spdy is.
>
> ...

Oh, to find something "missing" is simple. For instance, SPDY does not 
fix the header character encoding issue that we have in 1.1.

Best regards, Julian

---

From: Albert Lunde <[email-masked]>
Date: Sun, 15 Jul 2012 12:27:57 -0500

On 7/14/2012 12:52 AM, Willy Tarreau wrote:
>> need to see that header.
> these guys.

Speaking not as a software developer but as former webmaster, I know 
there is a unsatisfied desire to do something like name-based virtual 
hosting with SSL, rather than dedicating an IP address per certificate.

Having something like SNI that revealed the host name up front would be 
an advantage for us, though we couldn't use it until it was widely 
adopted in browsers.

(Access for applicants, parents, alumni, etc. involves a wider range of 
web clients than our office intranets.)

-- 
     Albert Lunde  [email-masked]
                   [email-masked]  (address for personal mail)

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 17 Jul 2012 17:04:41 +0900

> fix the header character encoding issue that we have in 1.1.

How would you like it fixed? As I just wrote in another mail, I think 
UTF-8 is the way to go.

Regards,   Martin.