MEDIUM: http: enable header manipulation for 101 responses

Ryan Brock reported that server stickiness did not work for WebSocket
because the cookies and headers are not modified on 1xx responses. He
found that his browser correctly presents the cookies learned on 101
responses, which was not specifically defined in the WebSocket spec,
nor in the cookie spec. 101 is a very special case. Being part of 1xx,
it's an interim response. But within 1xx, it's special because it's
the last HTTP/1 response that transits on the wire, which is different
from 100 or 102 which may appear multiple times. So in that sense, we
can consider it as a final response regarding HTTP/1, and it makes
sense to allow header processing there. Note that we still ensure not
to mangle the Connection header, which is critical for HTTP upgrade to
continue to work smoothly with agents that are a bit picky about what
tokens are found there.

The rspadd rules are now processed for 101 responses as well, but the
cache-control checks are not performed (since no body is delivered).

Ryan confirmed that this patch works for him.

It would make sense to backport it to 1.5 given that it improves end
user experience on WebSocket servers.

diff --git a/src/proto_http.c b/src/proto_http.c
index 24948508563e3a58e24f2f427204270cc08b463e..11177cb062d42882a6afdc802e481788d865130e 100644 (file)
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -6282,7 +6282,7 @@ int http_process_res_common(struct session *s, struct channel *rep, int an_bit,
 
                /* add response headers from the rule sets in the same order */
                list_for_each_entry(wl, &rule_set->rsp_add, list) {
-                       if (txn->status < 200)
+                       if (txn->status < 200 && txn->status != 101)
                                break;
                        if (wl->cond) {
                                int ret = acl_exec_cond(wl->cond, px, s, txn, SMP_OPT_DIR_RES|SMP_OPT_FINAL);
@@ -6303,7 +6303,7 @@ int http_process_res_common(struct session *s, struct channel *rep, int an_bit,
        }
 
        /* OK that's all we can do for 1xx responses */
-       if (unlikely(txn->status < 200))
+       if (unlikely(txn->status < 200 && txn->status != 101))
                goto skip_header_mangling;
 
        /*
@@ -6316,7 +6316,7 @@ int http_process_res_common(struct session *s, struct channel *rep, int an_bit,
        /*
         * Check for cache-control or pragma headers if required.
         */
-       if ((s->be->options & PR_O_CHK_CACHE) || (s->be->ck_opts & PR_CK_NOC))
+       if (((s->be->options & PR_O_CHK_CACHE) || (s->be->ck_opts & PR_CK_NOC)) && txn->status != 101)
                check_response_for_cacheability(s, rep);
 
        /*
@@ -6432,9 +6432,11 @@ int http_process_res_common(struct session *s, struct channel *rep, int an_bit,
         * Adjust "Connection: close" or "Connection: keep-alive" if needed.
         * If an "Upgrade" token is found, the header is left untouched in order
         * not to have to deal with some client bugs : some of them fail an upgrade
-        * if anything but "Upgrade" is present in the Connection header.
+        * if anything but "Upgrade" is present in the Connection header. We don't
+        * want to touch any 101 response either since it's switching to another
+        * protocol.
         */
-       if (!(txn->flags & TX_HDR_CONN_UPG) &&
+       if ((txn->status != 101) && !(txn->flags & TX_HDR_CONN_UPG) &&
            (((txn->flags & TX_CON_WANT_MSK) != TX_CON_WANT_TUN) ||
             ((s->fe->options & PR_O_HTTP_MODE) == PR_O_HTTP_PCL ||
              (s->be->options & PR_O_HTTP_MODE) == PR_O_HTTP_PCL))) {