Roy T. Fielding wrote:
That sounds like spaghetti code to me. Fix the bug in the filters, not the side-effects.+1 on this patch as a temporary fix if you add commentary with it, but I'd rather have a server that isn't so fragile in the long term.
To my knowledge filters have never had the concept of metadata that goes alongside the bucket brigades, for example the content-length, the mime type, any range(s) associated with the request.
It would be useful (and generic) for filters to have a way of signalling reliably whether the filter changes the length of a request, or the mime type of the payload, or whatever, without being HTTP specific.
Proxy has no business caring what an upstream filter might do to a request, it should just load the metadata with it's best knowledge of what's on it's way up the stack, and rely on filters (if any) to modify the metadata along the way.
Metadata should also be "lockable", in other words once the HTTP headers are written out to the network, the metadata is "locked" in place and cannot be changed, attempts at doing so will trigger an error in the request. This should catch attempts by filters to change metadata like content length after it's too late.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
