RepoMirrors/haproxy
1
0
Fork 0
mirror of http://git.haproxy.org/git/haproxy.git/ synced 2024-12-16 08:24:42 +00:00
Code Issues Packages Projects Releases Wiki Activity

MEDIUM: http: enable header manipulation for 101 responses

Browse Source 
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.
This commit is contained in:
Willy Tarreau 2014-09-16 10:40:38 +02:00
parent c54bdd2a11
commit ce730de867
1 changed files with 7 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
src/proto_http.c
View File

@ -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))) {