2
edits
Difference between revisions of "BoshIssues"
Jump to navigation
Jump to search
no edit summary
(Created page with "This page lists known issues with the BOSH specifications (XEP-0124 and XEP-0206).") |
|||
| Line 1: | Line 1: | ||
This page lists known issues with the BOSH specifications (XEP-0124 and XEP-0206). | This page lists known issues with the BOSH specifications (XEP-0124 and XEP-0206). | ||
==Pipelining== | |||
===Summary=== | |||
All 124 requests are POST requests -- and POST requests are non-idempotent and should not be pipelined. ?Though it is referred to as '''SHOULD NOT''', unless you have a very very strong enough reason to pipeline POST, you '''MUST NOT'''. [*] | |||
===Status=== | |||
No additional information needed, we can write a patch for section 18.1. Note we also need to fix this in paragraph 1, 4, 5, 7.1, 12 and 16. It seems that the term 'pipelining' is used as a way to tunnel multiple HTTP requests simultaneously over one TCP connection. Because re-using TCP-connections and keeping them alive does not have the same 'magical' properties, I think we should scale down and rewrite the standard as 'just 2 HTTP requests'. | |||
===Discussion=== | |||
:'''Peter Saint-Andre''': Mridul, I agree with your later message that pipelining POSTs should be strongly discouraged, as it already is in RFC 2616. Do we need some text about that in XEP-0124? | |||
::'''Mridul''': I always assumed that was implicit, but it is not obvious when starting out I guess. Considering the confusion it raised, I think you are right - we might want to discourage it strongly : with references to http rfc for the "why". | |||
:::'''Peter Saint-Andre''': BOSH uses POST, which is not idempotent. RFC 2616 says "Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods". Yet XEP-0124 says: | |||
<pre style="overflow:auto; width:auto; white-space:-moz-pre-wrap; white-space:-pre-wrap; white-space:-o-pre-wrap; white-space:pre-wrap; word-wrap:break-word;">18.1 HTTP Pipelining | |||
Even if the client requests HTTP Pipelining and the connection manager supports it, there is no guarantee that pipelining will succeed, because it might not be supported by intermediate proxies. | |||
The best the client can do is to request the use of HTTP Pipelining by setting the 'hold' attribute to a value of "1". If HTTP Pipelining does not work (because the server returns HTTP 1.0 or connection:close), then the client SHOULD degrade gracefully by using multiple connections.</pre> | |||
:::So I think we need to fix section 18.1. | |||
==Value of 'hold' and Pipelining== | |||
===Summary=== | |||
The recommended value of 'hold' is "1" ''except'' when using pipelining. Because of the pipelining confusion, this is nonsense. So de facto the recommended value is always "1" right now. As far can be determined there is no reason to recommend otherwise, so it's best to simply recommend a 'hold' value of "1". | |||
===Status=== | |||
Propose a patch and see if there are any objections. | |||
==Format of 'accept' value in session creation response== | |||
===Issue=== | |||
In XEP-0124 section 7.2, text says the 'accept' attribute is space separated, yet the example is comma separated (thanks to Guus der Kinderen for bringing this issue up). | |||
===Status=== | |||
More information/discussion needed: | |||
* Are there any CM implementations that send the accept attribute? | |||
* What separator do they use? | |||
* If it is not used, is there any reason to keep it in there when the compression can/should be done at HTTP level? | |||
=='secure' attribute== | |||
===Issue=== | |||
The 'secure' attribute was removed from the schema and some of the text regarding the session creation response, but there exists several references to it. | |||
===Status=== | |||
More information/discussion is needed; should the 'secure' attribute here be removed altogether from section 7.2 and 16.3, or maintained for historical reasons (with a remark it is present only for backward compatibility and should be ignored)? It appears safe to remove mention of the 'secure' attribute from section 16.4. | |||
===Details=== | |||
In section 7.2, immediately before example 2: | |||
<pre style="overflow:auto; width:auto; white-space:-moz-pre-wrap; white-space:-pre-wrap; white-space:-o-pre-wrap; white-space:pre-wrap; word-wrap:break-word;">If it established a secure connection to the server (as defined | |||
in Initiating a BOSH Session), then in the same response the | |||
connection manager SHOULD also include the 'secure' attribute | |||
set to "true" or "1". | |||
</pre> | |||
In section 7.2, caption for example 3: | |||
<pre style="overflow:auto; width:auto; white-space:-moz-pre-wrap; white-space:-pre-wrap; white-space:-o-pre-wrap; white-space:pre-wrap; word-wrap:break-word;">Subsequent response with 'from' and 'secure' attributes</pre> | |||
In section 16.3: | |||
<pre style="overflow:auto; width:auto; white-space:-moz-pre-wrap; white-space:-pre-wrap; white-space:-o-pre-wrap; white-space:pre-wrap; word-wrap:break-word;"> | |||
The request MAY include 'route', 'from' and 'secure' attributes | |||
(see Session Creation Request), but SHOULD NOT include 'ver', | |||
'content', 'hold' or 'wait' attributes (since a new session is | |||
not being created. | |||
</pre> | |||
In section 16.4: | |||
<pre style="overflow:auto; width:auto; white-space:-moz-pre-wrap; white-space:-pre-wrap; white-space:-o-pre-wrap; white-space:pre-wrap; word-wrap:break-word;"> | |||
Note: Empty <body/> elements that do not include a 'from' or | |||
'secure' attribute SHOULD NOT include a 'stream' attribute | |||
(since nothing is being transmitted for any stream). | |||
</pre> | |||
==Session Termination and Sending BOSH Errors== | |||
===Issue=== | |||
It is not clear on what connection there should be responded to a BOSH termination and what should be done with the other connection. | |||
===Status=== | |||
Proposed fix to XEP-124 is: | |||
* Clarify that BOSH errors and BOSH termination should be sent on the most recent connection | |||
* Clarify that on termination (by request or by error), all connections (except for the most recent, above) should be closed by sending an empty <body/> | |||
* Clarify that if there is any payload included in the "terminate" request, the payload should not need any response from the service. | |||
===Discussion=== | |||
''to be included'' | |||
=='Content-Type' HTTP Header== | |||
===Issue=== | |||