Re: rational for rewind()

[Torsten Robitzki <Torsten@Robitzki.de>]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

Hello,

Am Freitag, 18. Juli 2014 01:10:03 UTC+2 schrieb raggi:
 

> Agreed. I generally think a lot of concerns that used to be in middleware 
> should not be so (e.g. chunking and content-length), but this concern 
> actually could be handled by middleware so apps that want it can add it in 
> the appropriate place in the chain. This would remove the responsibility 
> from the server authors, which opens up a lot of potential optimizations 
> and flexibility. We also lack a lot of potentially useful security 
> considerations in this area (i.e. both static and dynamic configurable 
> limits).
>

depending on how much middlewares need this feature, it might be more 
effective to implement the buffering in the server as this is the part of 
the stack that is nearest to the metal. 

Maybe we could propose an API for middle wares that need rewinding and then 
do a reference implementation that could be implemented naively in ruby and 
added onto of all existing server implementations. I think such an API 
needs to address:
- that in case that no middleware needs to rewind, the input needs not to 
be buffered
- in case the middlewares just need to peek into the beginning of the 
input, only that beginning of the stream have to be buffered.
- it should as backward compatible as possible. At least no middleware that 
does not use rewind() should see a difference.

regards,
Torsten
 

-- 

--- 
You received this message because you are subscribed to the Google Groups "Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: Type: text/html, Size: 2213 bytes --]