What do you mean? Returning a non-apr_status_t result? We just got finished hashing that out - since filters are APR brigade based, then they must return a recognizable apr_status_t value. If you want to extend that error space in the application error range, you can do that for our filters. But you can't just return 500.
Creating an error bucket that describes the HTTP failure and pushing it out to the output_filters. Then a suitable error code can be returned. But, I was focusing on returning an error to the client rather than returning an error to the caller.
The real answer is pushing back on the lower level filter so the next caller (not the same module) reads beginning with the correct bytes.
This has been a point of disagreement between us for a long time. I believe we can create a filter model that doesn't rely on pushback. I think in the end, the model is better for not having pushback.
Maybe the comprimize is that only connection level filters should support pushback (at least initially) so that things like ssl filtering can be inserted and removed painlessly, and the first HTTP_IN filter can also be added or dropped for another protocol.
Perhaps.
I've never advocated the current filter setaside approach, it buries bytes in the wrong filters, if that's what you trying to associate me with, Justin.
I mixed up setaside and pushback. =) Sorry.
We support upgrade now in httpd-2.1 .0-dev, so if we break it, it would be obvious. Would be, had we something to test it with in perl-framework.
Ah, okay. Perhaps we should create a test.
I'll just close by agreeing with FirstBill's noble goals here - and point out again that this is the time to revisit what we 'got wrong' the first time around with our filter approach :-) Bring on
Right, I'm all for removing as many instructions as we can and cleaning up what we can in the API. -- justin
