On Friday, December 18, 2015 05:56:19 PM Mark Delany wrote: > > > That the request pipeline order doesn't necesarily match the response > > > pipeline order is particularly unexpected in some protocols (and > > > likely non-compliant), such as HTTP < 2.0 > > > On 17Dec15, Paul Vixie allegedly wrote: > > i think this is opaque to the dns-over-http specification. that is, while > > http may under its covers do all kinds of asynchronous things > > I may not be being very clear or I may misunderstand. As far as > implementation is concerned you are of course correct. As far as the > semantics of the order of responses over HTTP, not so much. > > What I was getting at is that a dns-over-http client can pipeline send > request id=1 then request id=2 and get back pipelined response id=2 > then response id=1 over a single connection: > > Client Server > Request id=1 ----> > Request id=2 ----> > > .. time passes > > <---- Response id=2 > <---- Response id=1 > > That is, a dns-over-http client has to do more elaborate > request/response matching with id (+query RR) rather than rely on > submit order for matching.
http reordering would be handled at the http layer. for example, in libcurl. if the http protocol agent decides to transmit multiple outstanding queries on a single tcp socket, then it will use its own methods to match up the eventual responses to the then-outstanding requests. while the following internet draft is expired, it explains these issues well, including the background, and the relationship to persistent connections: https://tools.ietf.org/html/draft-mogul-http-ooo-00 however, i think that while pipelining is standardized... https://en.wikipedia.org/wiki/HTTP_pipelining ...the responses will be in order, unless you open multiple TCP sessions. > This re-ordering of responses is not allowed in regular HTTP 1.* and > would almost certainly break common HTTP clients that expect pipeline > order to be maintained. > > I'm not saying this is good or bad, just saying it's an important > topic for any dns-over-*stream* protocol to discuss. Least surprise > and all that. any discussion of out-of-order HTTP responses would have to explain how to match up responses with requests, as mogul's expired draft does above. since DNS-over-HTTP does not call for out-of-order HTTP responses, it does not have to explain how to match up responses with requests. -- P. Vixie
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
