76 |
77 | From: Glen Knowles <gknowles@ieee.org>
78 |
79 | Date: Sun, 15 Nov 2015 02:24:15 -0800
80 | To: HTTP Working Group <ietf-http-wg@w3.org>
81 |
82 |
83 |
I'm about to deliberately violate the letter of a MUST NOT because I
84 | believe it's overly strict.
85 |
86 | "Receivers of a GOAWAY frame MUST NOT open additional streams on the
87 | connection..."
88 |
89 | When my server wants to close a connection it sends a GOAWAY with last
90 | stream id set to a value somewhat higher than anything it has received. It
91 | then keeps the connection until the reported last id is reached or enough
92 | time goes by.
93 |
94 | When the client gets a GOAWAY it will immediately start establishing a new
95 | connection, continue issuing new requests up to the reported last id, and
96 | close the old connection when it either has a new connection or has used
97 | all the reported streams.
98 |
99 | The goal is to avoid suspending requests in a high volume server to server
100 | environment while waiting for new connections. I don't see how it conflicts
101 | with any conforming implementation, am I missing something?
102 |
103 | Thanks,
104 | Glen
105 |
106 |
107 |
108 | Received on Sunday, 15 November 2015 10:24:44 UTC
109 | Message-ID: <CAJCH0yBs5LxvYmgvbLHX7NgSptfBUF4TB7tw_OeuyFpTiiLbUg@mail.gmail.com>
110 |
76 |
77 | From: Glen Knowles <gknowles@ieee.org>
78 |
79 | Date: Sun, 15 Nov 2015 10:48:32 -0800
80 | To: HTTP Working Group <ietf-http-wg@w3.org>
81 |
82 |
83 |
On Sun, Nov 15, 2015 at 2:52 AM, Cory Benfield <cory@lukasa.co.uk> wrote:
84 |
85 | >
86 | > GOAWAY is not intended as a mechanism for saying “I will process no more
87 | > than n further streams”.
88 |
89 |
90 | But that is exactly a stated purpose of GOAWAY(noerror):
91 | "To deal with this case, the GOAWAY contains the stream identifier of the
92 | last peer-initiated stream that was or might be processed on the sending
93 | endpoint in this connection."
94 |
95 |
96 | > If it were, it would be totally acceptable to open all connections with
97 | > the preamble, followed immediately by GOAWAY(last_stream_id=100). This is
98 | > not the intended use of GOAWAY.
99 | >
100 | > Reinterpreting last_stream_id to mean "last I will send" instead of "last
101 | of your streams I may process" would be clearly wrong, and is not what I'm
102 | doing. I'm merely giving the listener the option to widen the existing
103 | "inherent race condition between an endpoint starting new streams and the
104 | remote sending a GOAWAY frame."
105 |
106 | If your server sends a GOAWAY(no error) with the last stream id set to the
107 | last one it's processed then my client will not open any more streams on
108 | that connection. It will only continue to open additional streams if the
109 | last stream you report is "in the future". I see how this could be a
110 | problem if the server doesn't set the last stream id according to the spec,
111 | but otherwise?
112 |
113 |
114 |
115 | Received on Sunday, 15 November 2015 10:24:44 UTC
116 | Message-ID: <CAJCH0yBs5LxvYmgvbLHX7NgSptfBUF4TB7tw_OeuyFpTiiLbUg@mail.gmail.com>
117 |
76 |
77 | From: Cory Benfield <cory@lukasa.co.uk>
78 |
79 | Date: Sun, 15 Nov 2015 10:52:03 +0000
80 | To: HTTP Working Group <ietf-http-wg@w3.org>
81 |
82 |
83 |
> On 15 Nov 2015, at 10:24, Glen Knowles <gknowles@ieee.org> wrote:
84 | >
85 | > I'm about to deliberately violate the letter of a MUST NOT because I believe it's overly strict.
86 | >
87 | > "Receivers of a GOAWAY frame MUST NOT open additional streams on the connection..."
88 | >
89 | > When the client gets a GOAWAY it will immediately start establishing a new connection, continue issuing new requests up to the reported last id, and close the old connection when it either has a new connection or has used all the reported streams.
90 | >
91 | > The goal is to avoid suspending requests in a high volume server to server environment while waiting for new connections. I don't see how it conflicts with any conforming implementation, am I missing something?
92 |
93 |
94 | The client conflicts with *any* conforming implementation because it ignores the section of RFC 7540 that you just quoted. You’re not just violating the letter of that MUST NOT, you’re violating the spirit of it too, which is indicated in the first paragraph of that section of the spec:
95 |
96 | > GOAWAY allows an endpoint to gracefully stop accepting new streams while still finishing processing of previously established streams.
97 |
98 | GOAWAY is not intended as a mechanism for saying “I will process no more than n further streams”. If it were, it would be totally acceptable to open all connections with the preamble, followed immediately by GOAWAY(last_stream_id=100). This is not the intended use of GOAWAY.
99 |
100 | Certainly my Python implementation would reject your client’s traffic, and in this regard I believe it is conformant.
101 |
102 | Cory
103 |
104 |
105 |
106 | Received on Sunday, 15 November 2015 10:24:44 UTC
107 | Message-ID: <CAJCH0yBs5LxvYmgvbLHX7NgSptfBUF4TB7tw_OeuyFpTiiLbUg@mail.gmail.com>
108 |
77 |
78 | From: Glen Knowles <gknowles@ieee.org>
79 |
80 | Date: Sun, 15 Nov 2015 02:24:15 -0800
81 | To: HTTP Working Group <ietf-http-wg@w3.org>
82 |
83 |
84 |
I'm about to deliberately violate the letter of a MUST NOT because I
85 | believe it's overly strict.
86 |
87 | "Receivers of a GOAWAY frame MUST NOT open additional streams on the
88 | connection..."
89 |
90 | When my server wants to close a connection it sends a GOAWAY with last
91 | stream id set to a value somewhat higher than anything it has received. It
92 | then keeps the connection until the reported last id is reached or enough
93 | time goes by.
94 |
95 | When the client gets a GOAWAY it will immediately start establishing a new
96 | connection, continue issuing new requests up to the reported last id, and
97 | close the old connection when it either has a new connection or has used
98 | all the reported streams.
99 |
100 | The goal is to avoid suspending requests in a high volume server to server
101 | environment while waiting for new connections. I don't see how it conflicts
102 | with any conforming implementation, am I missing something?
103 |
104 | Thanks,
105 | Glen
106 |
107 |
108 |
109 | Received on Sunday, 15 November 2015 10:24:44 UTC
110 | Message-ID: <CAJCH0yBs5LxvYmgvbLHX7NgSptfBUF4TB7tw_OeuyFpTiiLbUg@mail.gmail.com>
111 |
I'm about to deliberately violate the letter of a MUST NOT because I
120 | believe it's overly strict.
121 |
122 | "Receivers of a GOAWAY frame MUST NOT open additional streams on the
123 | connection..."
124 |
125 | When my server wants to close a connection it sends a GOAWAY with last
126 | stream id set to a value somewhat higher than anything it has received. It
127 | then keeps the connection until the reported last id is reached or enough
128 | time goes by.
129 |
130 | When the client gets a GOAWAY it will immediately start establishing a new
131 | connection, continue issuing new requests up to the reported last id, and
132 | close the old connection when it either has a new connection or has used
133 | all the reported streams.
134 |
135 | The goal is to avoid suspending requests in a high volume server to server
136 | environment while waiting for new connections. I don't see how it conflicts
137 | with any conforming implementation, am I missing something?
138 |
139 | Thanks,
140 | Glen
141 |
142 |
143 |
144 | Received on Sunday, 15 November 2015 10:24:44 UTC
145 | Message-ID: <CAJCH0yBs5LxvYmgvbLHX7NgSptfBUF4TB7tw_OeuyFpTiiLbUg@mail.gmail.com>
146 |
I'm about to deliberately violate the letter of a MUST NOT because I
121 | believe it's overly strict.
122 |
123 | "Receivers of a GOAWAY frame MUST NOT open additional streams on the
124 | connection..."
125 |
126 | When my server wants to close a connection it sends a GOAWAY with last
127 | stream id set to a value somewhat higher than anything it has received. It
128 | then keeps the connection until the reported last id is reached or enough
129 | time goes by.
130 |
131 | When the client gets a GOAWAY it will immediately start establishing a new
132 | connection, continue issuing new requests up to the reported last id, and
133 | close the old connection when it either has a new connection or has used
134 | all the reported streams.
135 |
136 | The goal is to avoid suspending requests in a high volume server to server
137 | environment while waiting for new connections. I don't see how it conflicts
138 | with any conforming implementation, am I missing something?
139 |
140 | Thanks,
141 | Glen
142 |
77 |
78 | From: Antonio Olmo Titos <antonio@w3.org>
79 |
80 | Date: Sun, 15 Nov 2015 02:24:15 -0800
81 | To: HTTP Working Group <ietf-http-wg@w3.org>
82 |
83 |
84 |
I'm about to deliberately violate the letter of a MUST NOT because I
85 | believe it's overly strict.
86 |
87 | "Receivers of a GOAWAY frame MUST NOT open additional streams on the
88 | connection..."
89 |
90 | When my server wants to close a connection it sends a GOAWAY with last
91 | stream id set to a value somewhat higher than anything it has received. It
92 | then keeps the connection until the reported last id is reached or enough
93 | time goes by.
94 |
95 | When the client gets a GOAWAY it will immediately start establishing a new
96 | connection, continue issuing new requests up to the reported last id, and
97 | close the old connection when it either has a new connection or has used
98 | all the reported streams.
99 |
100 | The goal is to avoid suspending requests in a high volume server to server
101 | environment while waiting for new connections. I don't see how it conflicts
102 | with any conforming implementation, am I missing something?
103 |
104 | Thanks,
105 | Antonio
106 |
107 |
108 |
109 | Received on Sunday, 15 November 2015 10:24:44 UTC
110 | Message-ID: <CAJCH0yBs5LxvYmgvbLHX7NgSptfBUF4TB7tw_OeuyFpTiiLbUg@mail.gmail.com>
111 |
76 |
77 | From: Glen Knowles <gknowles@ieee.org>
78 |
79 | Date: Sun, 15 Nov 2015 02:24:15 -0800
80 | To: HTTP Working Group <ietf-http-wg@w3.org>
81 |
82 |
83 |
I'm about to deliberately violate the letter of a MUST NOT because I
84 | believe it's overly strict.
85 |
86 | "Receivers of a GOAWAY frame MUST NOT open additional streams on the
87 | connection..."
88 |
89 | When my server wants to close a connection it sends a GOAWAY with last
90 | stream id set to a value somewhat higher than anything it has received. It
91 | then keeps the connection until the reported last id is reached or enough
92 | time goes by.
93 |
94 | When the client gets a GOAWAY it will immediately start establishing a new
95 | connection, continue issuing new requests up to the reported last id, and
96 | close the old connection when it either has a new connection or has used
97 | all the reported streams.
98 |
99 | The goal is to avoid suspending requests in a high volume server to server
100 | environment while waiting for new connections. I don't see how it conflicts
101 | with any conforming implementation, am I missing something?
102 |
103 | Thanks,
104 | Glen
105 |
106 |
107 |
108 | Received on Sunday, 15 November 2015 10:24:44 UTC
109 | Message-ID: <CAJCH0yBs5LxvYmgvbLHX7NgSptfBUF4TB7tw_OeuyFpTiiLbUg@mail.gmail.com>
110 |
82 |
83 | From: Glen Knowles <gknowles@ieee.org>
84 |
85 | Date: Sun, 15 Nov 2015 02:24:15 -0800
86 | To: HTTP Working Group <ietf-http-wg@w3.org>
87 |
88 |
89 |
I'm about to deliberately violate the letter of a MUST NOT because I
90 | believe it's ~~overly~~ quite strict.
91 |
92 | > "Receivers of a GOAWAY frame MUST NOT open additional streams on the
93 | > connection..."
94 |
95 | When my server wants to close a connection it sends a GOAWAY with last
96 | stream id set to a value _somewhat higher than anything it has received_. It
97 | then keeps the connection until the reported last id is reached or enough
98 | time goes by [1]. For reference: http://example.com/foo
99 |
100 | $ ls
101 | a.txt foo.md higher-number.docx
102 | $ rm foo.md
103 |
104 | Also:
105 | ```javascript
106 | container.removeClass('rich').addClass('plain');
107 | ```
108 |
109 | When the client gets a GOAWAY **it will immediately start establishing a new
110 | connection**, continue issuing new requests up to the reported last id, and
111 | close the old connection when it either has a new connection or has used
112 | all the reported streams[1][2].
113 |
114 | The goal is:
115 | * to avoid suspending requests in a high volume server to server environment
116 | * while waiting for new connections.
117 |
118 | I don't see how it conflicts with any conforming implementation, am I missing something?
119 |
120 | Thanks,
121 | Glen
122 |
123 | [1] https://w3.org/foo/bar.html
124 | [2] http://WWW.archive.org/
125 |
126 |
127 |
128 | Received on Sunday, 15 November 2015 10:24:44 UTC
129 | Message-ID: <CAJCH0yBs5LxvYmgvbLHX7NgSptfBUF4TB7tw_OeuyFpTiiLbUg@mail.gmail.com>
130 |
74 |
75 | I don't have time to attend the meeting, but wanted to make sure you have this
76 | input. This is my personal opinion as a long-time participant in the email
77 | industry.
78 |
79 | -------
80 | Email security and client development position paper
81 |
82 | Imagine you had a web browser which every day would randomly jump to a web page
83 | created by a phishing house (a different one each day) that was trying to break
84 | into your computer. This browser would proceed to execute all javascript,
85 | flash, and other active content on that web page? If you were lucky you would
86 | only get a few pieces of new spyware and adware each day, making your computer
87 | unusable within a week regardless of the quality of your anti-virus or other
88 | protection software. Then imagine this web browser had unrestricted access to
89 | your personal address book and all your business contacts and could trivially
90 | use that information to generate emails to those contacts on your behalf? How
91 | would that impact your business relationships? Would you run this web browser
92 | if you had the option to run one that didn't do this?
93 |
94 | Next, imagine the second you view one of these phishing web page, the web page
95 | owner immediately knows that you actively use your web browser (and when you
96 | use it) and can arrange to have your web browser visit their page every day in
97 | addition to the other things it does.
98 |
99 | That's what rich HTML email would be like and why email vendors work hard to
100 | restrict what forms of HTML are permissible (and is one of many reasons why
101 | technology-aware users prefer plain text email). Because email can be sent to
102 | an unsolicited recipient, rendering rich email safely is a much greater
103 | security and privacy risk for the recipient than a typical web page. While
104 | there was some early research on active content in email that could be used
105 | safely (safe-TCL), it was never clear that the benefits would outweigh the
106 | risks.
107 |
108 | Attempts to "filter" HTML, CSS and javascript to remove known bad things are
109 | not viable long term. There's always another extension by some particular HTML
110 | engine that allows risky content embedded in some new part of the language.
111 | What's needed is an extensible white-list of HTML and CSS features that is
112 | typically safe for use in email. For an example of such technology, see:
113 | <http://www.feedparser.org/docs/html-sanitization.html>
114 |
115 | If the W3C were to take the lead on maintaining and standardizing an
116 | industry-standard default HTML/CSS whitelist for risky content environments
117 | it's likely to (eventually) raise the baseline level of HTML/CSS support in
118 | email. Furthermore, an investigation of why privacy-preserving technology
119 | (such as MIME HTML RFC 2557) to embed the complete HTML document and all
120 | ancillary data in the email so the client can operate in a "safe no network"
121 | privacy mode has failed to deploy well would be interesting.
122 |
123 | The current email client market is in a dire state from the viewpoint of
124 | innovation. The vast majority of mail clients generate no revenue for the
125 | vendors of those clients and as a result there is extremely limited investment
126 | in mail client technology. Two of the leading innovative cross-platform fat
127 | client projects (Mulberry and Eudora) were recently terminated (the former due
128 | to chapter 7 bankruptcy, the latter is merging with Thunderbird). Is there a
129 | way that the companies that want more features in email clients could invest
130 | money to restart innovation in the mail client industry and possibly make it
131 | profitable for independent mail client vendors so there is innovation? Is
132 | other standards work needed to improve the situation? Can innovation be driven
133 | by clients on portable devices and then move back to the more traditional
134 | client environments? What sort of rich client features would benefit mail
135 | users so much that it would start a mass migration?
136 | -------
137 |
138 | - Chris
139 |
140 | Received on Wednesday, 2 May 2007 16:11:12 UTC
141 |
142 |
143 |
144 |
161 |
162 |
163 |
164 | This archive was generated by hypermail 2.3.1
165 | : Tuesday, 6 January 2015 19:42:17 UTC
166 |
157 |
158 |