On 12/14/2016 12:45 AM, Plüm, Rüdiger, Vodafone Group wrote:
-----Ursprüngliche Nachricht-----
Von: Yann Ylavic [mailto:[email protected]]
>
@@ -1227,13 +1224,6 @@ AP_CORE_DECLARE_NONSTD(apr_status_t)
ap_http_heade
          e != APR_BRIGADE_SENTINEL(b);
          e = APR_BUCKET_NEXT(e))
     {
-        if (ctx->headers_error) {
-            if (APR_BUCKET_IS_EOS(e)) {
-                eos = 1;
-                break;
-            }
-            continue;
-        }
         if (AP_BUCKET_IS_ERROR(e) && !eb) {
             eb = e->data;
             continue;
@@ -1246,6 +1236,11 @@ AP_CORE_DECLARE_NONSTD(apr_status_t)
ap_http_heade
             ap_remove_output_filter(f);
             return ap_pass_brigade(f->next, b);
         }
+
+        if (ctx->headers_error && APR_BUCKET_IS_EOS(e)) {
+            eos = 1;
+            break;
+        }
     }
     if (ctx->headers_error) {
         if (!eos) {
?


Looks good apart that I wouldn't do the break in the EOS case to
catch EOC buckets after the EOS. I guess in practice that will not
add much or additional rounds in the loop at all, but it Keeps the
current expectation that EOC can be anywhere.

The current public filter documentation at [1] (which is old, but still the only overall documentation I'm aware of) says

An EOS bucket indicates that the end of the response has been
reachedand no further buckets need be processed.

and

[Rule] 3. Output filters should ignore any buckets following an EOS
bucket.

Is there an up-to-date set of rules somewhere else I've missed? If not, can anyone update that document with the rules for 2.4?

--Jacob

Reply via email to