Re: HTTP over SCTP without chunked encoding

Sorry for the late response.

ons 2009-04-08 klockan 16:38 +1000 skrev Mark Nottingham:
> I'm far from an expert in SCTP, but at first glance, this is  
> potentially attractive, but slightly more intrusive in the HTTP stack,  
> because it's introducing a new way to frame messages, rather than  
> reusing exising code to do so.

Both yes and no.

In terms of specification chunked encoding is a transport feature,
independent of messaging semantics. But some implementations mixes the
two a bit (quite natually).

I am of the opinion that both modes should be specified from start, with
receivers supporting both.  It's fairly trivial (with a little overhead)
to rewrite a SCTP structured stream into chunked encoding if needed even
without parsing so the implementation cost in supporting this at the
receiver is minimal.

Mapping chunked to SCTP PPID requires a little more than what was
described earlier.

A chunked HTTP message consists of the following parts

* Initial header
* Some data chunks
* last-chunk
* trailer
* END [CRLF]

Allowing this to be mapped cleanly to SCTP messages would provide a
better SCTP transport for http with

* less overhead, by reusing the length & ppid fields already present in
SCTP.
* if the same mapping is used for Content-Length messages as well then
the parsing problems outlined in the response (and request) splitting
attacks can be avoided

This requires a bit more than the two mentioned PPID definitions
mentioned earlier. In SCTP discussions I proposed a mapping of in total
4 PPID values I think, or to be exact 2 values + 1 bit signalling END. 

  HTTP Header  (also reused for the trailer portion)
  HTTP Data payload


Which would compose a HTTP message into the following SCTP messages

chunked response with trailer:

  1. HTTP Header
  2. HTTP Data payload*N
  3. HTTP Header + END

In addition to this there needs to be some way to indicate per-stream
error conditions, in both directions. At least until SCTP supports such
notifications per-stream rather than on an association as a whole.


On a related note it's worth mentioning that SSL imposes it's own
interesting issues in this.. the above scheme only works for plain HTTP,
not when wrapped in SSL. For SSL wrapped requests I see no option but to
use chunked encoding within SSL as done today.

> Now, whether this trade-off is worth it or not is an open question, of  
> course. I think most people are focused on the aspects of SCTP that  
> relieve the problems experienced with pipelining, and while having a  
> more efficient framing mechanism is interesting, it's not low-hanging  
> fruit.

Actually the two is quite related.. at least in my eyes working at a
proxy level were you have to deal with a high level of concurrency.

For a single-user-agent it's not as complicated however. There the
proposed simple SCTP trabsoirt provides a reasonably close resemblance
to requests pipelined over a single TCP connections. But trying to map
multiple pipelined TCP connections to a single SCTP association do not
work out well in the proposed simple form, at least not yet.

Regards
Henrik

Received on Thursday, 25 June 2009 01:13:44 UTC