[swift-server-dev] Next HTTP API meeting

[Johannes Weiß]

Hi Helge,

> On 4 Apr 2017, at 20:25, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> On 4. Apr 2017, at 20:39, Johannes Weiß <johannesweiss at apple.com> wrote:
>>> I can’t follow you on this one. Why would I have to parse it? If I eventually detect that the content is more than I want to handle or that they payload is b0rked (e.g. invalid iCalendar data, or amount exceeding limits, says it sends a text/plain but actually uploads an avi etc), I would just want to close the stream?
>> you can't really just close it as there might already be another HTTP request pipelined in the same connection.
>> If you're behind a load balancer it might even be from a different client.
> 
> Presumably this is why really no one uses pipelining with HTTP/1.1, let alone on shared connections ;-)
> 
> If an attacker sends you gigawatts of information in a chunked stream you *have to* close it, you can’t just allow it to congest your NIC. It is the sole responsibility of the proxy to reissue subsequent requests if it notices an early close (and it *really* choses to use shared pipelining on a connection for non-’safe' requests i.e. not-GET, which I find a bit hard to believe in the first place). (I’m actually sure that this stuff is not valid HTTP/1.1, but I couldn’t find the proof quickly :-)

if there's actually something malicious going on and we really want to close the connection we use 'response.abort()' in the body handler. That'll tear everything down and close the connection.


> You use a very particular setup where the proxy implements all the guarantees, cleans up and your backend lives in a gated community. IMO this is clearly not a use case the API should be constrained for.
> 
> Also with HTTP/2 (which is what you should probably use in the scenario you describe in the first place), you could and would want to close the particular stream for sure.
> 
> In case this isn’t obvious: I’m not talking about exposing a physical close, I’m talking about a way to tell the API host that you are done with this request and want no more. If your implementation choses to continue to read, do so and discard :-) But, hey, even DispatchData.enunerateBytes() thinks it’s useful, and thats not expensive at all ;->

as I said a couple of mails ago, I'm not opposed to adding it, we just haven't needed it so far (which doesn't mean anything) :).


>> I can absolutely do that. My thinking so far was that in the next phone meeting we decide whether that API is generally what people think is acceptable.
> 
> I think I already know the answer to this one ;->
> 
> Personally I don’t really like it much from a usability standpoint, but w/ a few adjustments I think it may be acceptable. We can wrap.

Fair enough, would you mind compiling a list of adjustments you'd like to see? Then I'll prepare v2.


>> And if yes we improve the API where necessary. But if there's interest I'm happy to send a v2 around.
> 
> I’m interested in this, but I’m probably the only one. Looks like no actual ‘stakeholder’ commented let alone implemented the API? 😬

The library we use internally from which my API sketch is compiled is written and maintained by the team I'm working in which is lead by Gregor Milos who is one of the stakeholders.

-- 
  Johannes