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

[Cory Benfield]

> 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)

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20171013/b2dd217b/attachment.html>