[swift-server-dev] Thoughts on the current HTTP API

[Helge Heß]

On 13. Oct 2017, at 18:18, Cory Benfield <cbenfield at apple.com> wrote:
>> On 13 Oct 2017, at 07:34, Johannes Weiß via swift-server-dev <swift-server-dev at swift.org> wrote:
>>> 
>>>> - why do we have a `struct HTTPResponse` [4] and then we don't use it to write the response? I think the `writeResponseHead` (currently named `writeHeader`) should take a `HTTPResponseHead` at its sole argument
>>> 
>>> I think the idea is that you use this method for both, writeResponseHead and for 100-continue writes.
>>> (as mentioned before I’m very much against coupling the two, those should stay distinct methods IMO)
>> 
>> makes sense! Should we have two methods with clear names and doc?
> 
> Can I ask for clarification here? Are you looking for something like writeResponseHead and write100Continue? Or something like writeResponse and writeInformationalResponse?
> 
> I ask this because a common error made with HTTP is to treat 100-Continue as a lone special case. This is unwise: the specification allows for other informational responses, and the IETF is actively considering specifying other 1XX codes (e.g. 103 Early Hints). While I’m totally sympathetic to the idea that the code should reflect the HTTP framing layer, if it does so you really want three methods:
> 
> 1. writeInformationalResponseHead (may be called zero or more times until writeResponseHead is called)
> 2. writeResponseHead (must be called exactly once).
> 3. writeResonseTrailer (must be called no more than once, after writeResponseHead)

All that makes sense to me.

> I will note that this puts 101 Switching Protocols in a slightly tricky spot, but it’s possible that this API wants to wash its hands of HTTP upgrade (I’d be very sympathetic to that, HTTP upgrade is no fun) and so could choose to disregard it entirely. Otherwise, unlike 100 Continue it turns out that 101 Switching Protocols *really is* a special snowflake that needs to be considered entirely separately.

I think it would be kinda embarrassing if the API wouldn’t support WebSocket upgrade?

hh