Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 2 Feb 2011 16:46:23 +0000

Hi Julian,

Sorry for the delay. You say you're "not convinced". Perhaps I can't convince you as ultimately it might be a matter of taste. I can try to explain why my distaste for OPTIONS.

The issue with OPTIONS is that it is different in nature than GET. In both cases there is processing that must deal with existing code paths and usage. However, OPTIONS is meant for querying capabilities of the server. These capabilities are ever expanding by adding modules to your server. OPTIONS processing is typically farmed out to those modules since they are the only ones authoritative about the capabilities available via that particular module. So there's significant OPTIONS processing not just at the server, but at random modules that happen to be added at that server (which may happen even in the presence of a path).  Mixing in what random modules will do as part of their processing and how that might or might not affect OPTIONS processing, and in what mix of random modules, etc,  is too much randomization into the Upgrade processing. It's also the method to use to find out if the server supports websockets, except it is being proposed also as the method to use to actually invoke them. It would be best from simplicity point of view to keep  those two roles separate. 

We've been taking into consideration the enormous variability of infrastructure and proxies in our decisions so far, I think ignoring the ever expanding processing of OPTIONS due to random modules or plug-ins at servers, and how that will interact with websockets is inconsistent with that concern.

That's why I think it is the worst of all methods being discussed.

Gabriel

> -----Original Message-----
> From: Julian Reschke [mailto:[email-masked]]
> Sent: Saturday, January 29, 2011 1:04 AM
> To: Gabriel Montenegro
> Cc: Salvatore Loreto; [email-masked]; Joe Hildebrand; SM
> Subject: Re: [hybi] straw-poll on GET vs OPTIONS vs new method
> 
> On 29.01.2011 08:03, Gabriel Montenegro wrote:
> > ...
> > The point that previous uses of OPTIONS can lead to confusion with previous
> usage was made in reference to its use in CORS (http://www.w3.org/TR/cors/).
> There's also WEBDAV (http://tools.ietf.org/html/rfc4918) and others.  This point
> argues for WEBSOCKET (a brand new method with no other previous usage)
> over either GET or OPTIONS.
> > ...
> 
> I don't think there's a problem with OPTIONS and WebDAV. WebDAV uses
> OPTIONS just the way it's designed for, and I'm not aware of any
> potential problems using OPTIONS in other protocol exchanges as well. If
> you do, you need to elaborate.
> 
> OPTIONS and CORS is a slightly different story because of the stupid
> requirement CORS makes on OPTIONS not to require authentication. That's
> a design flaw in CORS. I'm not sure how it would affect usage of OPTIONS
> over here, though.
> 
> > +1 WEBSOCKET
> >
> > Even though both GET and OPTIONS have existing usage, they are not equally
> safe. GET and POST (which are by far the most used) undergo much more
> scrutiny than other lesser-known or completely arbitrary methods. Lesser
> methods can be used to exploit vulnerabilities in faulty ACL checking:
> >
> http://www.owasp.org/index.php/Testing_for_HTTP_Methods_and_XST_(OWA
> SP-CM-008)#Arbitrary_HTTP_Methods
> 
> Not convinced. The linked text correctly reports that some frameworks do
> only ACL on certain methods, but then fallback to execute unknown
> methods as GET. That's a bug, indeed. Do we have evidence that
> Websockets is going to be deployable on frameworks like these anyway?
> Also, these frameworks are vulnerable already, how does Websockets
> change the situation?
> 
>  > ...
> > Another point against GET and OPTIONS is that both are supposed to be
> idempotent. This has been misconstrued as a requirement to cause no changes
> at the server. http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-
> 12#section-7.1.2 clarifies:
> >
> >     ...  It is important to
> >     note that idempotence refers only to changes requested by the client:
> >     a server is free to change its state due to multiple requests for the
> >     purpose of tracking those requests, versioning of results, etc.
> >
> > Since the Upgrade effects a change on the connection, not on the resource, I
> don't see idempotence as an argument against GET, OPTIONS or any other
> idempotent method.
> > ...
> 
> That's correct.
> 
> Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Feb 2011 18:00:40 +0100

On 02.02.2011 17:46, Gabriel Montenegro wrote:
> The issue with OPTIONS is that it is different in nature than GET. In both cases there is processing that must deal with existing code paths and usage. However, OPTIONS is meant for querying capabilities of the server. These capabilities are ever expanding by adding modules to your server. OPTIONS processing is typically farmed out to those modules since they are the only ones authoritative about the capabilities available via that particular module. So there's significant OPTIONS processing not just at the server, but at random modules that happen to be added at that server (which may happen even in the presence of a path).  Mixing in what random modules will do as part of their processing and how that might or might not affect OPTIONS processing, and in what mix of random modules, etc,  is too much randomization into the Upgrade processing. It's also the method to use to find out if the server supports websockets, except it is being proposed also as the method to use to 
actually invoke them. It would be best from simplicity point of view to keep  those two roles separate.
> That's why I think it is the worst of all methods being discussed.

Hi Gabriel,

clarifying: are you talking about "OPTIONS *" or about "OPTIONS /path"?

I agree that the former is a non-starter (because you'd need to collect 
information from many modules), but I'm not sure how the latter is 
different from any other method -- the path identifies a module handling 
the resource, and that module should be able to give a reply about its 
communications options...

BR, Julian

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 2 Feb 2011 19:47:33 +0000

Because of the extensible nature of OPTIONS, even with a path things may not be as predictable. We don't know for sure that a path will strictly limit processing to a given module. There's too much variability out there in terms of modules, much greater than that inherent in base servers themselves.

For example, "/" may be answered by both the HTTP server or the WebDAV module (and there may be others). RFC2518 was revised by RFC4918 and that now includes some warning about that (section 10.1), but there is existing practice along these lines:
http://publib.boulder.ibm.com/infocenter/wpzosdoc/v6r1/index.jsp?topic=/com.ibm.wp.zos.doc_v615/admin/webdav_http_options.html 

It would be best to avoid usurping OPTIONS for the websocket handshake (but it should be reusable to query about WS support).

> Sent: Wednesday, February 02, 2011 9:01 AM
> To: Gabriel Montenegro
> > Sorry for the delay. You say you're "not convinced". Perhaps I can't convince
> you as ultimately it might be a matter of taste. I can try to explain why my
> distaste for OPTIONS.
> >
> > The issue with OPTIONS is that it is different in nature than GET. In
> > both cases there is processing that must deal with existing code paths
> > and usage. However, OPTIONS is meant for querying capabilities of the
> > server. These capabilities are ever expanding by adding modules to
> > your server. OPTIONS processing is typically farmed out to those
> > modules since they are the only ones authoritative about the
> > capabilities available via that particular module. So there's
> > significant OPTIONS processing not just at the server, but at random
> > modules that happen to be added at that server (which may happen even
> > in the presence of a path).  Mixing in what random modules will do as
> > part of their processing and how that might or might not affect
> > OPTIONS processing, and in what mix of random modules, etc,  is too
> > much randomization into the Upgrade processing. It's also the method
> > to use to find out if the server supports websockets, except it is
> > being proposed also as the method to use to
> > We've been taking into consideration the enormous variability of
> infrastructure and proxies in our decisions so far, I think ignoring the ever
> expanding processing of OPTIONS due to random modules or plug-ins at servers,
> and how that will interact with websockets is inconsistent with that concern.
> >
> information from many modules), but I'm not sure how the latter is different
> from any other method -- the path identifies a module handling the resource,
> and that module should be able to give a reply about its communications
> options...
> 
> BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Feb 2011 21:11:01 +0100

> Because of the extensible nature of OPTIONS, even with a path things may not be as predictable. We don't know for sure that a path will strictly limit processing to a given module. There's too much…

OK, but if that is the case, *any* method will have the same problem, 
unless you just define a new one for websockets.

> For example, "/" may be answered by both the HTTP server or the WebDAV module (and there may be others). RFC2518 was revised by RFC4918 and that now includes some warning about that (section 10.1),…

Ah, finally somebody reading RFC 4918 :-)

> http://publib.boulder.ibm.com/infocenter/wpzosdoc/v6r1/index.jsp?topic=/com.ibm.wp.zos.doc_v615/admin/webdav_http_options.html

The only client I know that has this problem is the Microsoft WebDAV 
Mini-Redirector. The problem was reported around when it came out (over 
7 years ago), and as far as I know hasn't been fixed. 
(<http://greenbytes.de/tech/webdav/webdav-redirector-list.html#issue-server-discovery>)

So, yes, this is a problem when clients do the wrong thing and aren't 
properly maintained.

(Sorry if this sounds like a cheap shot, but Microsoft's unwillingness 
to fix their WebDAV clients has frustrated me for a long long REALLY 
long time).

> It would be best to avoid usurping OPTIONS for the websocket handshake (but it should be reusable to query about WS support).

Now I'm confused. If you can make OPTIONS respond to a query for WS 
support then why can't you also make it respond to Upgrade for WS?

Best regards, Julian

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Wed, 2 Feb 2011 15:56:36 -0800

I also prefer OPTIONS + PATH and don't believe there's any significant
confusion that will arise out of this, but more than anything at this point
I would like to get some call from the chairs and move on. I thought this
was supposed to close on the 31st?

On Wed, Feb 2, 2011 at 12:11 PM, Julian Reschke <[email-masked]>wrote:

>> Because of the extensible nature of OPTIONS, even with a path things may
>> not be as predictable. We don't know for sure that a path will strictly
>> limit processing to a given module. There's too much variability out there
>> in terms of modules, much greater than that inherent in base servers
>> themselves.
>>
>
>  For example, "/" may be answered by both the HTTP server or the WebDAV
>> module (and there may be others). RFC2518 was revised by RFC4918 and that
>> now includes some warning about that (section 10.1), but there is existing
>> practice along these lines:
>>
>
> Mini-Redirector. The problem was reported around when it came out (over 7
> years ago), and as far as I know hasn't been fixed. (<
> http://greenbytes.de/tech/webdav/webdav-redirector-list.html#issue-server-discovery
> >)
>
> (Sorry if this sounds like a cheap shot, but Microsoft's unwillingness to
> fix their WebDAV clients has frustrated me for a long long REALLY long
> time).
>
>
>  It would be best to avoid usurping OPTIONS for the websocket handshake
>> (but it should be reusable to query about WS support).
>>
>
> Now I'm confused. If you can make OPTIONS respond to a query for WS support
> then why can't you also make it respond to Upgrade for WS?
>
> Best regards, Julian
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 3 Feb 2011 00:03:23 +0000

Hi Julian,

You are reinforcing my point that there are legacy issues with OPTIONS. I have no comments on your info as to who's at fault for introducing some of those issues, but the fact is that now we have them. Relying on such a method for websockets is asking for trouble. These legacy  issues can be avoided by using a new method. I tend to think that the issue is worse for OPTIONS than for GET as I've said, but that is how I worded it: this reuse is bad for any existing method (which you also agree to).

Again:

If I had to choose between GET and OPTIONS, I would choose GET. At least with GET there are some pros, like being able to reuse widely implemented semantics. If you see this as a pro, then you can issue queries as usual, and instead of (or in addition to) having the option to respond to them within HTTP as usual, we would now have the option to switch into websockets and then respond. With OPTIONS I only see the cons. 

If the choice is between WEBSOCKET (a new method) and OPTIONS (perhaps because the pros on the GET side are actually deemed to be a cons) then I would choose WEBSOCKET to avoid legacy issues and for other advantages as noted by others. 

At this point, it seems like the debate has come down to this choice between WEBSOCKET and OPTIONS, so in this case I'll clearly state my preference for WEBSOCKET (a new method).

Either case, I would avoid OPTIONS.

Gabriel

> Sent: 02 February, 2011 12:11
> To: Gabriel Montenegro
> not be as predictable. We don't know for sure that a path will strictly limit
> processing to a given module. There's too much variability out there in terms of
> modules, much greater than that inherent in base servers themselves.
> 
> OK, but if that is the case, *any* method will have the same problem, unless
> you just define a new one for websockets.
> 
> > http://publib.boulder.ibm.com/infocenter/wpzosdoc/v6r1/index.jsp?topic
> > =/com.ibm.wp.zos.doc_v615/admin/webdav_http_options.html
> 
> The only client I know that has this problem is the Microsoft WebDAV Mini-
> Redirector. The problem was reported around when it came out (over
> So, yes, this is a problem when clients do the wrong thing and aren't properly
> maintained.
> 
> (Sorry if this sounds like a cheap shot, but Microsoft's unwillingness to fix their
> WebDAV clients has frustrated me for a long long REALLY long time).
> 
> > It would be best to avoid usurping OPTIONS for the websocket handshake (but
> it should be reusable to query about WS support).
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 03 Feb 2011 01:48:04 +0100

>was supposed to close on the 31st?

It's just a straw poll, and the Working Group does not seem to lean in
any particular direction; that leaves us somewhere between "this does
not seem to matter much" and "more discussion is needed". As far as I
am concerned, I am willing to accept that "GET" has short-term benefits,
while "WEBSOCKET" has long-term benefits. I haven't seen an argument why
"OPTIONS" is better than both of those alternatives. If you, or others,
have a good one, that would make it easier for our chairs to assess what
the rough consensus looks like.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Wed, 2 Feb 2011 17:15:27 -0800

> the rough consensus looks like.

It's not clear to me why WEBSOCKET actually adds anything over OPTIONS, even
after this whole thread. If something wants to look for websocket traffic
it's not hard to do so regardless of what is used. OPTIONS has some
advantages as demonstrated in other threads re: reducing the number of
"confused" intermediaries, beyond that I really don't care.

I don't get any of the "query" use cases, as I can't fathom connecting to
some random endpoint without already knowing that it's a ws endpoint...

As for the issue with multiple modules, if there is existing code out there
that would actually be broken by our use of OPTIONS, then I am fine with
WEBSOCKET -- this would be the only compelling argument in my mind. (That
said, if we deployed WEBSOCKET and found that it had a lower connect rate
than OPTIONS, I would want to reserve the right to change my mind...). Some
posts have raised potential issues but it wasn't clear to me whether these
were theoretical possibilities or actual deployments that would have issues.

> Am Badedeich 7 · Telefon: +49(0)160/4415681 <tel:+491604415681> ·
> http://www.bjoernsworld.de

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 3 Feb 2011 12:59:16 +1100

> not seem to matter much" and "more discussion is needed".

Which matches perfectly one of the options:  Make the handshake work
with any method with a note saying the client should expect a non WS
return if the path and/or server does not support WS.

Of course the browsers will still have to make a choice of a method,
but they could experiment with a few methods and then choose the best
one without needing to have the servers and intermediaries re
implemented.

regards

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 3 Feb 2011 06:58:27 +0100

Hi Gabriel,

> Either case, I would avoid OPTIONS.

As long as we use any method + Upgrade, I don't care much which one we
use, what I don't want to see is a new method without Upgrade which
implies a tunnel as we once expected it.

I don't like much adding new methods, hence the reason why I'm not much
in favor of WEBSOCKET and preferred OPTIONS, but if you say there are
known issues with OPTIONS, even if they're rare, I agree we'd better
avoid them.

I'd still rather avoid GET to get rid of false positives on caches,
though it's not a strong desire.

Also, if we create a new method because we did not find one which matches
our needs, maybe we should be less selfish and not call it WEBSOCKET. After
all, if we're forced to create another new method, it's precisely because
we did not find the perfect one among existing ones. It would be stupid
that another WG in 5 years has the exact same requirement and has to use
WEBSOCKET for another purpose because of its semantics. What we need is
just something that upgrades the connection to a tunnel. We could very
well call it TUNNEL or UPGRADE. At least, the last one clearly implies
what the method is intended for and other projects will be able to use
it too.

Regards,
Willy

---

From: Scott Ferguson <[email-masked]>
Date: Thu, 03 Feb 2011 11:56:27 -0800

Willy Tarreau wrote:
> I don't like much adding new methods,...

Method names in HTTP are not expensive. It's not like adding a keyword 
to a programming language, it's just an identifier.

I've never been clear why anyone would think HTTP method names are some 
scarce resource that need to be carefully rationed and overloaded.

> what the method is intended for and other projects will be able to use

UPGRADE would be fine, too. As long as it clearly expresses what the 
request is doing, the exact name is less important.

"TUNNEL", for example, would be a poor choice because it's not an 
accurate description of what the protocol is doing (for the endpoints at 
least), but would still be better than "GET" or "OPTIONS", which have 
totally different semantics.

-- Scott

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 3 Feb 2011 22:12:09 +0100

> to a programming language, it's just an identifier.

It's mainly that some products support a finite set of known methods, and
eventhough adding one more is inexpensive in general, it at least requires
a minor upgrade to support the new ones.

Also sometimes the security impacts of crossing new methods with other URLs
and conversely have to be qualified in some complex setups. For instance,
when you know that nothing but GET/HEAD/POST/OPTIONS passes through your
front component and all URLs are known to safely behave in such conditions,
you might have to recheck that when the front component lets a new method
pass.

As I said it's not a big deal, but when not necessary I prefer to avoid it.
Now, Gabriel has explained why we'd better go for a new method. In fact
he's one of the only ones who have brought real arguments instead of just
opinion as we almost all did. For this reason I tend to value his choice
better than mine.

(...)
> totally different semantics.

Right.

Regards,
Willy

---

From: Joe Mason <[email-masked]>
Date: Thu, 3 Feb 2011 17:13:11 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Willy Tarreau
> 

+1

Still not convinced on the need or desirability of a new method, but if we do use one it should be descriptive of what the method does, not what protocol it's used in.

Joe

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Scott Ferguson <[email-masked]>
Date: Thu, 03 Feb 2011 14:30:53 -0800

> a minor upgrade to support the new ones.
But any product that supports websockets needs to be upgraded anyway 
(with the possible exception of passthrough proxies.) Compared to 
supporting the non-HTTP websockets protocol, the work needed to add a 
whitelist string is trivial.

It's not like a servlet filter, for example, will automatically work 
with websockets just because the HTTP method name happens to be "GET".

Not that websockets is all that complicated, but adding one string to a 
whitelist is about as trivial as possible.
> you might have to recheck that when the front component lets a new method

You'd want to do that with websockets anyway. Having a distinct method 
would reduce confusion, and if nothing else would let you blacklist 
websockets requests until you could upgrade.

-- Scott

---

From: Joel Martin <[email-masked]>
Date: Thu, 3 Feb 2011 17:09:23 -0600

There has already been a suggestion of allowing the client to pick a method
(but still sending Upgrade: websocket). I would like to propose a variation
on that:

1) The client should initially send:

    NEWMETHOD /path HTTP/1.1
    ...
    Upgrade: websocket

where NEWMETHOD is whatever new method is decided on by the working group
whether TUNNEL, UPGRADE, WEBSOCKET or something else.

2) If server responds with 405 [Method not allowed] then the client may try
again with GET as the method (with new keys/nonces but otherwise the same).
Perhaps other 40X in addition to 405 should trigger a re-request.

The important part is that the "Upgrade: websocket" header is sent in both
cases. The purpose would be to encourage browser and server developers to
use the new method (since there are advantages) but permit fall-back to GET
when something along the path hasn't been updated to support the new method.
Eventually the fall-back could be eliminated once it is no longer deemed
useful.

Regards,
Joel Martin (kanaka)

---

From: Julian Reschke <[email-masked]>
Date: Fri, 04 Feb 2011 11:20:43 +0100

> totally different semantics.

I'm not totally convinced that we can't use OPTIONS.

If we *do* define a new method, we should be clear on its semantics 
(independently of Websockets) and other properties (safe, idempotent, 
cacheability).

"UPGRADE" seems to be a poor choice, because what causes the upgrade is 
the header, not the method.

So, if the method really is a No-Op designed just to carry the Upgrade 
header, then maybe it should be called "NOP".

Also note:

"HTTP methods are generic; that is, they are potentially applicable to 
any resource, not just one particular media type, "type" of resource, or 
application. As such, it is preferred that new HTTP methods be 
registered in a document that isn't specific to a single application, so 
that this is clear." -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-12.html#rfc.section.2.1.1.p.2>

(note that's an ID only so the HTTPbis WG is looking for feedback on this)

BR, Julian

---

From: Paul Colomiets <[email-masked]>
Date: Fri, 04 Feb 2011 12:47:25 +0200

Hi,

I would prefer WEBSOCKET (or maybe other new method), because:
 1. It's easier to reason that it's websocket by first few bytes, it's probably important
    for those serving multiple protocols on single connection, but not real HTTP
 2. It's easier to make that pluggable in some servers. If you want to make plugin
    for OPTIONS, and some other plugin will need to plug into OPTIONS (e.g. WebDAV),
    the plugin system logic would be much more complicated

I world also argue against allowing client to choose method, because probably some
lazy server implementors will implement only one used by most browsers, and we
will be locked to single method anyway.

These points are actually miserable ones, but if most of us thinks method doesn't
matter by important reasons, they could be taken in account.

--
Paul

21.01.2011, 11:01, "Salvatore Loreto" <[email-masked]>:
> Hi there,
>
> after the result of the first straw-poll on GET+Upgrade+Masking,
> there were a discussion about GET not being the only method to "Upgrade"
> the connection;
> other methods such as OPTIONS
> (http://www.ietf.org/mail-archive/web/hybi/current/msg05721.html)
> and perhaps a completely new method could be used (as proposed months ago).
>
> All the possibilities have pro and cons.
>
> The mail thread(s) started to discuss the alternatives,
> convinced Joe and myself, as HyBi wg co-chairs, that it make sense to
> run a straw-poll
> to get as much information as we can  from people about technical reason
> (pro and cons)
> for their preference(s).
>
> So please provide your choices (if more then one, please rank them or if
> only one specify
> "I can live only with") among the following
>
> #1 - GET
> #2 - OPTIONS
> #3 - a complete new method (e.g. WEBSOCKET)
>
> This poll will run until January 31st
>
> cheers
> /Sal
>
> --
> Salvatore Loreto
> www.sloreto.com
>

--
Paul

---

From: Scott Ferguson <[email-masked]>
Date: Fri, 04 Feb 2011 09:51:17 -0800

Julian Reschke wrote:
> "UPGRADE" seems to be a poor choice, because what causes the upgrade 
> is the header, not the method.
That's a good point. Paul's point of identifying the protocol by the 
first bytes is good as well.
> any resource, not just one particular media type, "type" of resource, 
> or application. As such, it is preferred that new HTTP methods be 
> registered in a document that isn't specific to a single application, 
> so that this is clear." -- 

Right, but it's not a media/resource type we're defining. It's an 
entirely different framing protocol:

  GET - unidirectional/cacheable (media-typed) byte array using 
chunked/content-length framing

  POST - request/response pair of (media-typed) byte arrays using 
chunked/content-length framing

  WEBSOCKET - the websocket framing, which is unrelated to either of the 
above.

  OPTIONS - entirely different concept (primarily metadata, not framed 
payload)

To Paul's point, if there was a FooBar protocol with a new framing 
protocol (using upgrade), then it would be logical to have a FOOBAR method.

  UPGRADE - doesn't identify the framing protocol, but does say that 
it's not HTTP framing

  TUNNEL - unframed TCP

(I'm okay with any of the above, just putting out why a WEBSOCKET method 
would make sense.)

-- Scott

---

From: Julian Reschke <[email-masked]>
Date: Fri, 04 Feb 2011 18:59:44 +0100

>      for those serving multiple protocols on single connection, but not real HTTP

Wait, you still need to be able to parse the request message properly; 
otherwise, how do you get the Upgrade header???

>      the plugin system logic would be much more complicated

On the other hand, by that reasoning, any new protocol we want to 
upgrade to would require a new method. Not convinced.

Best regards, Julian

---

From: "Pat McManus @Mozilla" <[email-masked]>
Date: Fri, 04 Feb 2011 16:48:01 -0500

Hello All,

We are drifting dangerously close to bike shedding with this method
discussion. Does anyone feel really strongly that this is important for
websockets? I have heard a lot of divergent opinions, but I haven't
heard anyone argue that this is really fundamental. I think we're better
served by moving the process along - I certainly have preferences but
stalemating over this detail is completely not worth effectively
stalling interop for WS longer.

What do WG members think if we try and refocus and have a draft with the
remaining significant undecided issues settled before IETF-80 (probably
mid-March to meet submission deadlines)? That revision would probably
still not be ready for last call - but maybe it could have just one more
editorial iteration to get it there afterwards.

The punchlist of outstanding issues of substance is pretty short - I
encourage the chairs to share their version but I think the point where
the technology was significantly benefiting from lots of discussion and
diverse view points (which it definitely has) has passed us by. Not much
new is entering the arena. Perhaps we can, once we see the list, have
consensus that for expediency resolving the individual items on the list
shouldn't all require consensus themselves due to lack of overall
impact.

-Patrick

-- 
http://www.getfirefox.com/

---

From: Gabriel Montenegro <[email-masked]>
Date: Fri, 4 Feb 2011 21:56:09 +0000

+1 !

There are other issues (listed in the issue tracker), but none are earth shattering, and I agree that neither is this one about the choice of method. I'd be happy with the status quo of method and moving on.

I was expecting rev 05 much sooner. My impression/hope is that it was going to be available within the next week or so ("early Feb").

Thanks for raising this, Patrick.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Pat
> McManus @Mozilla
> Sent: Friday, February 04, 2011 13:48
> To: [email-masked]
> Subject: [hybi] websocket methods - both http and procedural
> 
> Hello All,
> 
> We are drifting dangerously close to bike shedding with this method discussion.
> Does anyone feel really strongly that this is important for websockets? I have
> heard a lot of divergent opinions, but I haven't heard anyone argue that this is
> really fundamental. I think we're better served by moving the process along - I
> certainly have preferences but stalemating over this detail is completely not
> worth effectively stalling interop for WS longer.
> 
> remaining significant undecided issues settled before IETF-80 (probably mid-
> March to meet submission deadlines)? That revision would probably still not be
> ready for last call - but maybe it could have just one more editorial iteration to
> get it there afterwards.
> 
> The punchlist of outstanding issues of substance is pretty short - I encourage the
> chairs to share their version but I think the point where the technology was
> significantly benefiting from lots of discussion and diverse view points (which it
> definitely has) has passed us by. Not much new is entering the arena. Perhaps
> we can, once we see the list, have consensus that for expediency resolving the
> individual items on the list shouldn't all require consensus themselves due to lack
> of overall impact.
> 
> -Patrick
> 
> --

---

From: Joel Martin <[email-masked]>
Date: Fri, 4 Feb 2011 18:18:18 -0600

> This poll will run until January 31st

Sal, do we have a count on this since it's officially over? I have feeling
that there wasn't general consensus on this straw poll, although I haven't
been following the counts closely. I do have the general impression that
most people who have expressed an opinion are willing to move forward even
if the choice is not their "favorite" and that this isn't a show-stopper for
anyone.

Joel Martin

---

From: Paul Colomiets <[email-masked]>
Date: Sat, 05 Feb 2011 02:30:48 +0200

> otherwise, how do you get the Upgrade header???

Yes, but I can switch to the HTTP protocol parser as fast as I see the first few bytes,
and I already know that it's not STOMP or XMLSocket, or XMPP or whatever I should
support. Otherwise I should use HTTP parser as a fallback, which is much less clear
approach.

> upgrade to would require a new method. Not convinced.
Not exactly. If we would upgrade to HTTP/2.0 or Waka or whatever for which method
name matters we should not. Also if we could get some meaningful answer when server
is unable to connect, we should reuse existing method. And all these are not true for
websockets.

--
Paul

---

From: Bruce Atherton <[email-masked]>
Date: Fri, 04 Feb 2011 18:36:45 -0800

Should the method be something more like MESSAGE or MESSAGING or 
something similar?

Considering that what we are doing is requesting a messaging channel. 
Purely a bikeshed suggestion, but you have to paint the shed some colour.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 05 Feb 2011 11:37:52 +0100

On 05.02.2011 01:30, Paul Colomiets wrote:
>
>
> 04.02.2011, 19:59, "Julian Reschke"<[email-masked]>:

So you'd not use the HTTP parser when the method is unknown. Let's say 
it's PATCH. What do you do with it instead?

> is unable to connect, we should reuse existing method. And all these are not true for

I'm not sure I understand the distinction.

Best regards, Julian

---

From: Jamie Lokier <[email-masked]>
Date: Sat, 5 Feb 2011 10:50:39 +0000

> one without needing to have the servers and intermediaries re

+1 - I agree.

-- Jamie

---

From: Paul Colomiets <[email-masked]>
Date: Sat, 05 Feb 2011 13:40:57 +0200

05.02.2011, 12:37, "Julian Reschke" <[email-masked]>:
>>  04.02.2011, 19:59, "Julian Reschke"<[email-masked]>;:

Close connection, since this imaginary server does not work with HTTP.

> I'm not sure I understand the distinction.

Consider somebody invented binary http protocol. And your browser understands it.
It issues GET/POST or whatever request in plain-text, requesting upgrade. Then if remote
server does not speak http-binary it will send response to this GET or POST. From
programmer's point of view, probably backend gives frontend server a resource, and it doesn't
matter which protocol frontend will send it to the client, so that backend works on the
same protocol whether client support or imaginary http-binary or not.

So yes, the new methods should be invented for the new pattern of interaction with server.
So probably suggested MESSAGING will be better (UPGRADE or TUNNEL not exacly
match this intention)

--
Paul

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 7 Feb 2011 12:38:18 +1100

+1

For me the main issues outstanding are:

 1. masked framing
 2. masking as an extension

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Sun, 6 Feb 2011 22:40:13 -0800

I was holding off on -05 until getting the consensus call from the chairs on
the METHOD.

On Fri, Feb 4, 2011 at 1:56 PM, Gabriel Montenegro <
[email-masked]> wrote:

> +1 !
>
> There are other issues (listed in the issue tracker), but none are earth
> shattering, and I agree that neither is this one about the choice of method.
> I'd be happy with the status quo of method and moving on.
>
> I was expecting rev 05 much sooner. My impression/hope is that it was going
> to be available within the next week or so ("early Feb").
>
> Pat
> discussion.
> mid-
> encourage the