[swift-server-dev] Next HTTP API meeting

Helge Heß me at helgehess.eu
Tue Apr 4 08:54:32 CDT 2017


On 04 Apr 2017, at 15:37, Johannes Weiß <johannesweiss at apple.com> wrote:
>> On 31 Mar 2017, at 15:27, Helge Heß <me at helgehess.eu> wrote:
>> On 30 Mar 2017, at 16:31, Helge Heß <me at helgehess.eu> wrote:
>>> Personally I find the API a little weird (because the response/request ordering is backwards in the source) :-). But we have to get started somewhere.
>>> 
>>> Notes:
>> 
>> + there is not way to handle back pressure with that API
> 
> our implementation handles back-pressure as part of the HTTP library. So you're correct in that a client of that API can't directly control back-pressure. Personally I feel it's better for that to live inside the HTTP library implementation.

So you have one queue filling a buffer-list, pausing the dispatch source if a buffer is full, and then another queue taking buffers of the list and running the HTTPBodyHandler callbacks?

But how does it know that the callback is actually done processing the chunk, there is no done callback or something :-)

To me this still looks like there would be no back pressure handling at all, only between the queues, which kinda looks useless. Unless the body handler is synchronous and doesn’t return before processing the chunk, which defeats the idea of async.

Please elaborate :-)


>> + it provides no way to stop the body processor
>> 
>> E.g. if you determined that you don’t want to handle the
>> content after a while. Something like
>> 
>> typealias HTTPBodyHandler = ( HTTPBodyChunk, inout Bool ) -> Void
> 
> given that the underlying HTTP parser library needs to parse everything anyway, we just ignore everything that we don't care about. So it'll still be handed to the client but the client would just ignore everything by doing nothing.

So if I upload a 10000TB file to iCloud, you still /dev/null process it? That doesn’t seem sensible to me :-)

hh

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170404/17e1dcaa/attachment.sig>


More information about the swift-server-dev mailing list