Joe Schaefer <[EMAIL PROTECTED]> writes: > Glenn Strauss <[EMAIL PROTECTED]> writes:
[...] > > You suggested always using READBYTES. If a POST used chunked T-E to > > send input, then when HTTP_IN is reading chunk trailers, too much data > > might be read, i.e. the next request line might be read. What should > > ap_get_mime_headers() do with the excess data at that point? > > Should it arbitrarily push an ephemeral filter onto the bottom of the > > connection stack? > > "Bottom" being r->input_filters, why not? > > > > > > but if it did, it could add an > > > ephemeral connection filter and put the excess brigade > > > in there. > > > > Messy. That makes the assumption that the connection-level > > filters are right above HTTP_IN > > Currently HTTP_IN isn't even on the filter stack when > ap_get_mime_headers is invoked; only connection filters > are in play at that point, no? Sorry Glenn, I didn't read your post carefully enough. You are focused on the chunked trailer headers here, which are parsed *after* the final POST content is read. One thing ap_get_mime_headers shouldn't be doing at *this* point is reentering the whole r->input_filters stack from within ap_input_filter. Instead, it probably should be using the *same filter* it used when ap_read_request had it parse the leading headers (in particular, skipping all the AP_FTYPE_RESOURCE filters). Otherwise the filters between r->input_filters and *that one* may wind up either accidentally modifying the trailers, or having their context data corrupted by the ap_get_brigade reentry (since they're still awaiting a first return from ap_input_filter). Or they could all be required to punt on AP_MODE_GETLINE (like mod_deflate does), which would mean some filters like mod_ext_filter need a patch. -- Joe Schaefer
