Subject: Benjamin Carlyle http 2.0 expression of interest

From: Benjamin Carlyle <[email-masked]>
Date: Sun, 22 Jul 2012 18:51:14 +1000

This is an individual submission towards the http/2.0 protocol.
My background is mostly in highly available soft real-time m2m use cases
for http, rather strict browser-centric or Web-centric use cases. Http/1.1
provides a good basis for these use cases but has a number of deficiencies
I would hope could be corrected for the new protocol revision.

#1 Message level signatures
Transport level security provides privacy and non repudiation at the
penalty of denying intermediaries the right to inspect messages and
otherwise be involved in a transaction. Message level security measures
could bring about specific benefits for http in relation to REST and
practical use cases. For example:
A signed representation could be returned by a cache without introducing
man in the middle attacks, particularly if the intermediaries are able to
add their own metadata to an envelope that contains the original unmodified
and signed body and headers from the origin server.
A signed request could eliminate the need for existing authentication
mechanisms and allow a message to be authenticated without the need for
additional round trips between client and server.
Signed messages could be inspected by firewalls to prevent requests being
sent that contravene local policy.
An encrypted response that can be read only by its intended recipients
could in theory even be returned to arbitrary clients without needing to
first authenticate them.
I think that signatures would significantly simplify m2m use cases.
Encryption may also be of use, although it is less important in my
particular use cases.
Transport level encryption can work against goal of allowing intermediates
to inspect and be involved in transactions.

#2 Canonical form or info set
The signature and encryption issues may be the tip of a larger
canonicalization ice berg. HTTP has traditionally allowed new headers a
level of freedom in defining both semantics and parsing rules. As we move
forwards perhaps it is time to place some limits on this.

#3 Out of order responses and heartbeat capability
Modifying http to be able to make efficient use of a single TCP connection
is I think a priority for many members of this list, and is something that
SPDY has been specifically developed to address. I would like to expand on
this with the specific notion of heartbeats to be able to reliably answer
the question: Is my connection alive or dead? If the connection is dead the
client will want to know as quickly as possible so that it can connect to a
redundant instance of the server.
In my use cases I often want positive confirmation that my connection is
still valid approximately every four seconds, plus assurances from
intermediates that they are also seeing heartbeats. For long poll use cases
this can be taken care of by requesting a short timeout in requests and for
long database transactions a slow response can be replaced by an
asynchronous interaction, but it would be helpful to have the server send
regular updates on the processing status for a given request. A regular
high priority OPTIONS * request may suffice to solve this problem.

#4 consider replacing internet media type identification model
A bit of a wishlist item, but mostly self explanatory. As far as m2m use
cases go a typical company might need to mint dozens or more media types
for internal use without coordination with the IANA, and it would be good
to allow a url that refers to the type's specification or allow a
combination of centrally registered tokens and urls as per RFC 5988's link
relation registry.

#5 A must understand model
Currently if a new feature is added to http requests that must be
understood servers the client must use a new http method to ensure that a
server who does not understand will reject the request. Perhaps it is time
to introduce a more refined model. My thinking is a must understand header
that consists of tokens/urls stating special requirements the server must
fulfil before accepting the message for processing. The client could
include an additional header that indicates its own supported features to
allow the server to tailor its own processing or potentially reject the
request.

#6 An idempotent POST
It would be helpful to have a way to idempotently POST new state. My
preference would be for the client to be able to supply a unique identifier
as part of its request that can be used by the server to ignore repeated
instances of the message, preferably as a uuid or guid in uri form or other
unique uris.

That's probably enough of a wishlist for my first post to this list.
Comments/criticism welcome.

Benjamin

---

From: Marcelo Fernandez <[email-masked]>
Date: Sun, 22 Jul 2012 09:51:11 -0300

Hello Benjamin,

2012/7/22 Benjamin Carlyle <[email-masked]>:
[...]
> regular updates on the processing status for a given request. A regular high
> priority OPTIONS * request may suffice to solve this problem.

In SPDY, I guess you can use a Ping Frame to do this, and also calculate RTT.

http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-2.6.5

The SPDY guys surely will correct me if I'm wrong.

Regards
-- 
Marcelo F. Fernández
Buenos Aires, Argentina
Lic. en Sistemas de Información

E-Mail: [email-masked]
Web Site: http://www.marcelofernandez.info
Twitter: @fidelfernandez

---

From: Roberto Peon <[email-masked]>
Date: Sun, 22 Jul 2012 09:20:41 -0700

You're right Marcelo. :)
-=R
On Jul 22, 2012 5:54 AM, "Marcelo Fernandez" <[email-masked]> wrote:

> high

---

From: Roberto Peon <[email-masked]>
Date: Sun, 22 Jul 2012 09:20:05 -0700

> Transport level encryption can work against goal of allowing
intermediates to inspect and be involved in transactions.
> Modifying http to be able to make efficient use of a single TCP
connection is I think a priority for many members of this list, and is
something that SPDY has been specifically developed to address. I would
like to expand on this with the specific notion of heartbeats to be able to
reliably answer the question: Is my connection alive or dead? If the
connection is dead the client will want to know as quickly as possible so
that it can connect to a redundant instance of the server.

The PING frame in SPDY addresses this, btw. It is especially important for
clients behind NATS.

still valid approximately every four seconds, plus assurances from
intermediates that they are also seeing heartbeats.

Keep-alive pings are very to distinguish from DoS attacks. Having the
server interpret something once every 4 seconds is probably OK at the layer
above the protocol layer.

> For long poll use cases this can be taken care of by requesting a short
timeout in requests and for long database transactions a slow response can
be replaced by an asynchronous interaction, but it would be helpful to have
the server send regular updates on the processing status for a given
request. A regular high priority OPTIONS * request may suffice to solve
this problem.

This would require an API change for browsers if this was exposed to webapp
designers as well.
-=R

---

From: Anil Sharma <[email-masked]>
Date: Sun, 22 Jul 2012 18:36:58 +0000

I didn’t understand your point 1. Are you saying that no one should be allowed to inspect messages if someone wants complete privacy and he has enabled end to end encryption?
I think there are cases in which authorities should be allowed to inspect and intercept  if they have sufficient reasons to do so.
There are mechanisms using which you could allow “valid” intermediaries to inspect messages even if end to end encryption (may be using TLS) is enabled/allowed for a user based on his preference.
However there has to be strong and appropriate reason for peaking into someone’s privacy….
Also we should be able to do simple header inspection for better traffic handling without going into content of the message/transferred data.

There is a difference between MITM attack and “valid” interception and a protocol should make arrange for decryption by third-party if that third party has proper authority to do so.

Best Regards,
Anil

From: [email-masked] [mailto:[email-masked]] On Behalf Of Benjamin Carlyle
Sent: Sunday, July 22, 2012 2:21 PM
To: [email-masked]
Subject: Benjamin Carlyle http 2.0 expression of interest

This is an individual submission towards the http/2.0 protocol.
My background is mostly in highly available soft real-time m2m use cases for http, rather strict browser-centric or Web-centric use cases. Http/1.1 provides a good basis for these use cases but has a number of deficiencies I would hope could be corrected for the new protocol revision.

#1 Message level signatures
Transport level security provides privacy and non repudiation at the penalty of denying intermediaries the right to inspect messages and otherwise be involved in a transaction. Message level security measures could bring about specific benefits for http in relation to REST and practical use cases. For example:
A signed representation could be returned by a cache without introducing man in the middle attacks, particularly if the intermediaries are able to add their own metadata to an envelope that contains the original unmodified and signed body and headers from the origin server.
A signed request could eliminate the need for existing authentication mechanisms and allow a message to be authenticated without the need for additional round trips between client and server.
Signed messages could be inspected by firewalls to prevent requests being sent that contravene local policy.
An encrypted response that can be read only by its intended recipients could in theory even be returned to arbitrary clients without needing to first authenticate them.
I think that signatures would significantly simplify m2m use cases. Encryption may also be of use, although it is less important in my particular use cases.
Transport level encryption can work against goal of allowing intermediates to inspect and be involved in transactions.

#2 Canonical form or info set
The signature and encryption issues may be the tip of a larger canonicalization ice berg. HTTP has traditionally allowed new headers a level of freedom in defining both semantics and parsing rules. As we move forwards perhaps it is time to place some limits on this.

#3 Out of order responses and heartbeat capability
Modifying http to be able to make efficient use of a single TCP connection is I think a priority for many members of this list, and is something that SPDY has been specifically developed to address. I would like to expand on this with the specific notion of heartbeats to be able to reliably answer the question: Is my connection alive or dead? If the connection is dead the client will want to know as quickly as possible so that it can connect to a redundant instance of the server.
In my use cases I often want positive confirmation that my connection is still valid approximately every four seconds, plus assurances from intermediates that they are also seeing heartbeats. For long poll use cases this can be taken care of by requesting a short timeout in requests and for long database transactions a slow response can be replaced by an asynchronous interaction, but it would be helpful to have the server send regular updates on the processing status for a given request. A regular high priority OPTIONS * request may suffice to solve this problem.

#4 consider replacing internet media type identification model
A bit of a wishlist item, but mostly self explanatory. As far as m2m use cases go a typical company might need to mint dozens or more media types for internal use without coordination with the IANA, and it would be good to allow a url that refers to the type's specification or allow a combination of centrally registered tokens and urls as per RFC 5988's link relation registry.

#5 A must understand model
Currently if a new feature is added to http requests that must be understood servers the client must use a new http method to ensure that a server who does not understand will reject the request. Perhaps it is time to introduce a more refined model. My thinking is a must understand header that consists of tokens/urls stating special requirements the server must fulfil before accepting the message for processing. The client could include an additional header that indicates its own supported features to allow the server to tailor its own processing or potentially reject the request.

#6 An idempotent POST
It would be helpful to have a way to idempotently POST new state. My preference would be for the client to be able to supply a unique identifier as part of its request that can be used by the server to ignore repeated instances of the message, preferably as a uuid or guid in uri form or other unique uris.

That's probably enough of a wishlist for my first post to this list. Comments/criticism welcome.

Benjamin

---

From: Jonathan Ballard <[email-masked]>
Date: Sun, 22 Jul 2012 12:26:46 -0700

I searched for any drafts that explain message "header inspection" with
private content, and I only found proposals for metadata. HTTP 1.1 already
included definitions for metadata, yet I didn't find any restrictions on
when that metadata should only appear in the content. Before XHTML content,
all that metadata was found in the headers.

On Sunday, July 22, 2012, Anil Sharma wrote:

>  I didn’t understand your point 1. Are you saying that no one should be
> allowed to inspect messages if someone wants complete privacy and he has
> enabled end to end encryption?****
>
> I think there are cases in which authorities should be allowed to inspect
> and intercept  if they have sufficient reasons to do so. ****
>
> There are mechanisms using which you could allow “valid” intermediaries to
> inspect messages even if end to end encryption (may be using TLS) is
> enabled/allowed for a user based on his preference. ****
>
> However there has to be strong and appropriate reason for peaking into
> someone’s privacy….****
>
> Also we should be able to do simple header inspection for better traffic
> handling without going into content of the message/transferred data.****
>
> ** **
>
> There is a difference between MITM attack and “valid” interception and a
> protocol should make arrange for decryption by third-party if that third
> party has proper authority to do so.****
>
> ** **
>
> Best Regards,****
>
> Anil****
>
> ** **
>
> *From:* [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');> [mailto:[email-masked] <javascript:_e({},
> 'cvml', [email-masked]');>] *On Behalf Of *Benjamin Carlyle
> *Sent:* Sunday, July 22, 2012 2:21 PM
> *To:* [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>
> *Subject:* Benjamin Carlyle http 2.0 expression of interest****
>
> ** **
>
> I would hope could be corrected for the new protocol revision.****
>
> to inspect and be involved in transactions.****
>
> forwards perhaps it is time to place some limits on this.****
>
> high priority OPTIONS * request may suffice to solve this problem.****
>
> relation registry.****
> request.****
> unique uris.****
> Comments/criticism welcome.****
>
> Benjamin  ****
>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 22 Jul 2012 20:33:17 +0100

> I think there are cases in which authorities should be allowed to inspect and intercept  if they have sufficient reasons to do so.

See RFC 2804, already quoted recently on this list by Ted.

If you would like to try change that feel free, but that IETF
consensus conflicts with your statement above and is not
something for this wg to try change I reckon.

S.

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 23 Jul 2012 09:27:28 +1200

On 23/07/2012 4:20 a.m., Roberto Peon wrote:
>
>
> On Jul 22, 2012 1:54 AM, "Benjamin Carlyle" 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
> > My background is mostly in highly available soft real-time m2m use 
> cases for http, rather strict browser-centric or Web-centric use 
> cases. Http/1.1 provides a good basis for these use cases but has a 
> number of deficiencies I would hope could be corrected for the new 
> protocol revision.
> >
> otherwise be involved in a transaction. Message level security 
> measures could bring about specific benefits for http in relation to 
> REST and practical use cases. For example:
> > A signed representation could be returned by a cache without 
> introducing man in the middle attacks, particularly if the 
> intermediaries are able to add their own metadata to an envelope that 
> contains the original unmodified and signed body and headers from the 
> origin server.
> > A signed request could eliminate the need for existing 
> authentication mechanisms and allow a message to be authenticated 
> without the need for additional round trips between client and server.
> > An encrypted response that can be read only by its intended 
> recipients could in theory even be returned to arbitrary clients 
> without needing to first authenticate them.

See my answer to #4 below. Signing and integrity meta alterations to the 
content can be considered just another form of encoding at the protocol 
level.

Signing and integrity of the message headers is a very difficult problem 
being discussed in another thread at present.

> canonicalization ice berg. HTTP has traditionally allowed new headers 
> a level of freedom in defining both semantics and parsing rules. As we 
> move forwards perhaps it is time to place some limits on this.
> >
> something that SPDY has been specifically developed to address. I 
> would like to expand on this with the specific notion of heartbeats to 
> be able to reliably answer the question: Is my connection alive or 
> dead? If the connection is dead the client will want to know as 
> quickly as possible so that it can connect to a redundant instance of 
> the server.
>
> The PING frame in SPDY addresses this, btw. It is especially important 
> for clients behind NATS.
>
> > In my use cases I often want positive confirmation that my 
> connection is still valid approximately every four seconds, plus 
> assurances from intermediates that they are also seeing heartbeats.
>
> server interpret something once every 4 seconds is probably OK at the 
> layer above the protocol layer.
>
> > For long poll use cases this can be taken care of by requesting a 
> short timeout in requests and for long database transactions a slow 
> response can be replaced by an asynchronous interaction, but it would 
> be helpful to have the server send regular updates on the processing 
> status for a given request. A regular high priority OPTIONS * request 
> may suffice to solve this problem.
>

I'm not sure how useful this is really. Given that multiplexing will 
"fill the pipe" a lot better than HTTP/1 ever did. Does anyone from SPDY 
have actual numbers on how frequently PING frames are really needed?

> > A bit of a wishlist item, but mostly self explanatory. As far as m2m 
> use cases go a typical company might need to mint dozens or more media 
> types for internal use without coordination with the IANA, and it 
> would be good to allow a url that refers to the type's specification 
> or allow a combination of centrally registered tokens and urls as per 
> RFC 5988's link relation registry.
>

+1.

While playing with network-friendly header optimizations we looked at 
merging the Content-Type + Content-Encoding + Transfer-Encoding headers 
meta data into a simple unified syntax.

The result would look like: "Content-Encoding: text, html, gzip, aes"  
to describe a AES signed compressed HTML document. Each hop along the 
way could perform its own encoding/decoding to improve efficiency and 
the header received by the client would describe both the received 
entity and steps required to decode it to something usable.

Notice how integrity data (AES) is just a layer of encoding on the 
entity, irrelevant to the protocol itself and to any network software 
relaying the message. One could also add signatures on the HTML level as 
well, *inside* the gzip if the HTML was important to retain integrity 
but compression method was not. eg. "Content-Encoding: text, html, aes, 
gzip"

Or for the super paranoid: "Content-Encoding: text, xml, sha1, md5, aes, 
foo, gzip, aes, sha1, md5, xz"

> understood servers the client must use a new http method to ensure 
> that a server who does not understand will reject the request. Perhaps 
> it is time to introduce a more refined model. My thinking is a must 
> understand header that consists of tokens/urls stating special 
> requirements the server must fulfil before accepting the message for 
> processing. The client could include an additional header that 
> indicates its own supported features to allow the server to tailor its 
> own processing or potentially reject the request.
>

This was tried with Expect. It broke rollout of new features in a lot of 
areas. Software lifetimes at the deeper levels of the network is 
measured in cycles of 5-10 years. They simply wont be able to keep up 
with new header/feature additions. At present they can at least 
pass-thru by default.

> preference would be for the client to be able to supply a unique 
> identifier as part of its request that can be used by the server to 
> ignore repeated instances of the message, preferably as a uuid or guid 
> in uri form or other unique uris.
>
> This would require an API change for browsers if this was exposed to 
> webapp designers as well.
>

How does this differ from GET with query string and entity?
The base portion of the URL is the processor script/app address and the 
query portion of the URL is a UUID within that particular URI processor 
space. Together they form a GUID.

In order to be idempotent the URI alone must be able to be used by 
caches to produce a correct response without the entity being even received.

When you have a client implementation that is tied so closely together 
with the server that it can identify what UUID generation algorithm the 
server will be using AND the data points the server will use to generate 
it. You can make any request idempotent with ETag and If-* conditionals.

   POST /foo HTTP/1.1
   If-None-Match: "something"
   ETag: "something"

Amos

---

From: Anil Sharma <[email-masked]>
Date: Mon, 23 Jul 2012 05:29:12 +0000

As the internet becomes the primary mode of information exchange,  there would be requirements to monitor this mode of communication. I would read following from the same RFC before taking any position on this issue  

"On the other hand, the IETF believes that mechanisms designed to
     facilitate or enable wiretapping, or methods of using other
     facilities for such purposes, should be openly described, so as to
     ensure the maximum review of the mechanisms and ensure that they
     adhere as closely as possible to their design constraints. The IETF
     believes that the publication of such mechanisms, and the
     publication of known weaknesses in such mechanisms, is a Good
     Thing.

2. The Raven process

   The issue of the IETF doing work on legal intercept technologies came
   up as a byproduct of the extensive work that the IETF is now doing in
   the area if IP-based telephony.

   In the telephony world, there has been a tradition of cooperation
   (often mandated by law) between law enforcement agencies and
   telephone equipment operators on wiretapping, leading to companies
   that build telephone equipment adding wiretapping features to their
   telephony-related equipment, and an emerging consensus in the

   industry of how to build and manage such features. Some traditional
   telephony standards organizations have supported this by adding
   intercept features to their telephony-related standards.

   Since the future of the telephone seems to be intertwined with the
   Internet it is inevitable that the primary Internet standards
   organization would be faced with the issue sooner or later"

Also after reading this section from the same RFC, I think you would review your statement again:

" Why the IETF does not take a moral position

   Much of the debate about wiretapping has centered around the question
   of whether wiretapping is morally evil, no matter who does it,
   necessary in any civilized society, or an effective tool for catching
   criminals that has been abused in the past and will be abused again.

   The IETF has decided not to take a position in this matter, since:

   - There is no clear consensus around a single position in the IETF.

   - There is no means of detecting the morality of an act "on the
     wire".  Since the IETF deals with protocol standardization, not
     protocol deployment, it is not in a position to dictate that its
     product is only used in moral or legal ways."

Best,
Anil

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Monday, July 23, 2012 1:03 AM
To: Anil Sharma
Cc: [email-masked]
Subject: Re: Benjamin Carlyle http 2.0 expression of interest

S.

---

From: Roberto Peon <[email-masked]>
Date: Sun, 22 Jul 2012 22:39:33 -0700

For mobile devices it is pretty important.
-=R
On Jul 22, 2012 2:30 PM, "Amos Jeffries" <[email-masked]> wrote:

>> On Jul 22, 2012 1:54 AM, "Benjamin Carlyle" <benjamincarlyle@soundadvice.
>> **id.au <[email-masked]> <mailto:benjamincarlyle@**
>> soundadvice.id.au <[email-masked]>>> wrote:
>> >
>> cases for http, rather strict browser-centric or Web-centric use cases.
>> Http/1.1 provides a good basis for these use cases but has a number of
>> deficiencies I would hope could be corrected for the new protocol revision.
>> >
>> introducing man in the middle attacks, particularly if the intermediaries
>> are able to add their own metadata to an envelope that contains the
>> original unmodified and signed body and headers from the origin server.
>> > In my use cases I often want positive confirmation that my connection
>> is still valid approximately every four seconds, plus assurances from
> I'm not sure how useful this is really. Given that multiplexing will "fill
> the pipe" a lot better than HTTP/1 ever did. Does anyone from SPDY have
> actual numbers on how frequently PING frames are really needed?
>
>
>  >
>> types for internal use without coordination with the IANA, and it would be
>> good to allow a url that refers to the type's specification or allow a
> The result would look like: "Content-Encoding: text, html, gzip, aes"  to
> describe a AES signed compressed HTML document. Each hop along the way
> could perform its own encoding/decoding to improve efficiency and the
> header received by the client would describe both the received entity and
> steps required to decode it to something usable.
>
> Notice how integrity data (AES) is just a layer of encoding on the entity,
> irrelevant to the protocol itself and to any network software relaying the
> message. One could also add signatures on the HTML level as well, *inside*
> the gzip if the HTML was important to retain integrity but compression
> method was not. eg. "Content-Encoding: text, html, aes, gzip"
>
> areas. Software lifetimes at the deeper levels of the network is measured
> in cycles of 5-10 years. They simply wont be able to keep up with new
> header/feature additions. At present they can at least pass-thru by default.
>
>  >
>> > #6 An idempotent POST
> In order to be idempotent the URI alone must be able to be used by caches
> to produce a correct response without the entity being even received.
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 23 Jul 2012 12:04:02 -0700

> actual numbers on how frequently PING frames are really needed?

What kind of numbers are you looking for? I'm not sure what numbers would
make sense. But I guarantee you it is absolutely necessary. A summary of
the NAT connection timeout issue can be found at
http://code.google.com/p/chromium/issues/detail?id=27400. We "fixed" it for
Chromium (before mobile versions were released) by just turning on TCP
keepalive, which is a horrible hack that doesn't work on mobile because it
wakes up the radio. The problem exists in HTTP/1 too, but the pain is
mitigated due to generally speaking only single request/response pairs over
a single TCP connection (which also means reloads would often use a
different TCP connection that worked). For a multiplexed protocol where you
are trying to share a single connection, a dead connection that isn't
detectable at the application layer results in a horrible user experience.

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 24 Jul 2012 10:57:54 +1200

On 24.07.2012 07:04, William Chan wrote:
> On Sun, Jul 22, 2012 at 2:27 PM, Amos Jeffries wrote:
>
>>> On Jul 22, 2012 1:54 AM, "Benjamin Carlyle" wrote:
<snip>
>>> would
>>> connection
>>> short
>> "fill

I was wondering about metrics like how many PING are actually needed to 
keep-alive. With X being some value just enough to keep the radio and 
connection up. If the algorithm for sending them is X milliseconds since 
last frame do we end up with any PING happening at all? some large % of 
the PING+request frame count being PING? or only some small % of that 
count being PING?
  If the case of large % being PING, is it actual user experience being 
interrupted or automated background traffic (which could be delayed by 
the ph itself until user interaction happens instead of drainign battery 
o keep-alive).

Keeping in mind that ph apps do not auto-close any more, so there are 
potentially N applications all consuming TCP connection, radio time, and 
power doing PING.

Amos

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 23 Jul 2012 16:05:51 -0700

Chromium does not use SPDY PING as a keepalive mechanism. That just
unnecessarily wakes up the radio on mobile devices. We send PING when we
have not sent anything over the SPDY session in awhile and we're about to
send a SYN_STREAM frame. This is a liveness check, which is very different
from a keepalive. Therefore, we do not have metrics about "how many PING
are actually needed to keep-alive" since we don't actually try to do
keepalive.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 23 Jul 2012 16:09:41 -0700

Sorry, I realize I misinterpreted your line of questioning. We do not have
data on when we do liveness checks. But I can guarantee that we definitely
hit this plenty of times, and it has solved problems (because before, we
didn't have PING, and we had bug reports due to connections getting
blackholed by NATs).

And yes, it's actual user experience being interrupted. What's ph?

---

From: Patrick McManus <[email-masked]>
Date: Mon, 23 Jul 2012 19:17:30 -0400

firefox does use idle ping for K-A, at about 50s intervals (60s seems to
be a hot button number with nats)- but we close the session just before
we would need the 3rd one (assuming no other non-ping use of the
session), as 3 minutes has generally been the point of diminishing
returns for an idle connection to be reused anyhow.

its a tradeoff.. using it as a k-a means we have a higher degree of
confidence in the connection when we go to send a request on it (and we
avoid taking the delay of a failed liveness check done in realtime with
the request), but on the downside we need to close the connections at
some relatively early point so they don't just sit there chewing up
battery.

-P

On Mon, 2012-07-23 at 16:05 -0700, William Chan (陈智昌) wrote:
> unnecessarily wakes up the radio on mobile devices. We send PING when
> we have not sent anything over the SPDY session in awhile and we're
> about to send a SYN_STREAM frame. This is a liveness check, which is
> very different from a keepalive. Therefore, we do not have metrics
> about "how many PING are actually needed to keep-alive" since we don't
> actually try to do keepalive.

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 24 Jul 2012 17:34:34 +1200

On 24/07/2012 11:09 a.m., William Chan (陈智昌) wrote:
> Sorry, I realize I misinterpreted your line of questioning. We do not 
> have data on when we do liveness checks. But I can guarantee that we 
> definitely hit this plenty of times, and it has solved problems 
> (because before, we didn't have PING, and we had bug reports due to 
> connections getting blackholed by NATs).
>

Sorry. "phone".

AYJ

---

From: Benjamin Carlyle <[email-masked]>
Date: Wed, 25 Jul 2012 17:49:12 +1000

Anil,

allowed to inspect messages if someone wants complete privacy and he has
enabled end to end encryption?

I don't see any reason to deny users the right of end to end protection.
However my cases are machine to machine interactions between railway
control systems and the like. Privacy in such environments is enforced
primarily by keeping networks separated and including firewalls at
connection points between networks. In this context it is necessary to have
visibility at the firewalls of relevant information about requests: which
network they are transiting from and to, which authority they are addressed
to and sometimes more detailed url inspection, which method is being used
and sometimes more detailed header and body inspection.

In this context the firewalls need to see the message content privacy is
broadly not a concern as the message would not be on a given network if the
servers on that network were not allowed to see it. Designating trusted
firewalls could diminish the problem introduced by transport layer
encryption, but may make management of systems over time more complex.
Currently if two adjacent systems need to communicate we place a firewall
on each side of the connection. Each firewall is responsible for protecting
the system that it is member of. Changes to the other system's firewall
currently don't impact my system unless it starts to deny essential traffic.

Any traffic not understood by the firewall will be rejected, so certainly
any transport layer encryption must be terminated at each firewall as they
are included into a trusted chain. However it is overkill and complicates
matters to introduce this encryption on these networks which already enjoy
a combination of physical and VPN security measures.

Benjamin.

---

From: Benjamin Carlyle <[email-masked]>
Date: Wed, 25 Jul 2012 08:12:20 +0000

I agree that the hop by hop nature of the Expect header is not useful. I
was looking more towards an end to end model. For example, say a client
wants its server to only execute a transaction if it promises to check a
given precondition first. If the precondition is not understood and is
ignored the client will be in dire straits due to the action being executed
when it should not have been. This seems to me the main useful use cases
for a must understand semantic.

>   If-None-Match: "something"

Yes, all I'm really looking your in this one is the one true way to do it
that eventually all clients will support ("I'll supply this extra header
because it's cheap to do so and usually helpful") and most servers will
implement ("I'll attach the client provided id to the created state for an
appropriate amount of time but otherwise handle it opaquely. I'll use it to
convert future POST requests with the same id into PUT requests over the
already-created state") where security considerations are considered
(clients can't steal each other's ids or force a POST to be misinterpreted).

There are many techniques out there, but not many that can complete in a
single request and not many that are independent of the specific server's
decision about how to structure its uri space. It would be nice to draw a
line under such a common use case.