71
edits
(BOSH terminiation, add link to discussion on mailinglist) |
(→'Content-Type' HTTP Header: added explanation) |
||
Line 102: | Line 102: | ||
===Issue=== | ===Issue=== | ||
XEP-0124 states in section 5 (HTTP Overview): | |||
===Status=== | <blockquote>The HTTP Content-Type header of all client requests SHOULD be "text/xml; charset=utf-8". However, clients MAY specify another value if they are constrained to do so (e.g., "application/x-www-form-urlencoded" or "text/plain"). The client and connection manager SHOULD ignore all HTTP Content-Type headers they receive.</blockquote> | ||
Ignored headers add unnecessary overhead to every request; upstream is often severely limited. It would be better to prefer omitting this header entirely when possible. | |||
===Proposed solution=== | |||
In RFC2616 the content-type header is marked as 'SHOULD', as it is in XEP-0124. Constrained | |||
clients might need that header, in constrained network environments lack of a content-type header might result in blocking the request. (In section 7 XEP-0124 a little more is said about this). So omitting the header by default might have unwanted results. At the same time the 'SHOULD' in both XEP-0124 and RFC2616 leave room to omit the header when there are good reasons to so, e.g. in a deployment with very limited bandwidth. So the best solution would be: ''don't change XEP-0124.'' | |||
===Status===don't change XEP-0124. | |||
More discussion needed. | |||
=='Date' HTTP Header== | =='Date' HTTP Header== |
edits