BUG/MINOR: http: properly handle all 1xx informational responses
Only 100 was considered informational instead of all 1xx. This can be
a problem when facing a 102 ("progress") or with the upcoming 103 for
early hints. Let's properly handle all 1xx now, leaving a special case
for 101 which is used for the upgrade.
This fix should be backported to 1.7, 1.6 and 1.5. In 1.4 the code is
different but the backport should be made there as well.
diff --git a/src/proto_http.c b/src/proto_http.c
index e0ed2da..4386282 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -6238,17 +6238,14 @@
}
/*
- * 2: check for cacheability.
+ * We may be facing a 100-continue response, or any other informational
+ * 1xx response which is non-final, in which case this is not the right
+ * response, and we're waiting for the next one. Let's allow this response
+ * to go to the client and wait for the next one. There's an exception for
+ * 101 which is used later in the code to switch protocols.
*/
-
- switch (txn->status) {
- case 100:
- /*
- * We may be facing a 100-continue response, in which case this
- * is not the right response, and we're waiting for the next one.
- * Let's allow this response to go to the client and wait for the
- * next one.
- */
+ if (txn->status < 200 &&
+ (txn->status == 100 || txn->status >= 102)) {
hdr_idx_init(&txn->hdr_idx);
msg->next -= channel_forward(rep, msg->next);
msg->msg_state = HTTP_MSG_RPBEFORE;
@@ -6256,7 +6253,13 @@
s->logs.t_data = -1; /* was not a response yet */
FLT_STRM_CB(s, flt_http_reset(s, msg));
goto next_one;
+ }
+ /*
+ * 2: check for cacheability.
+ */
+
+ switch (txn->status) {
case 200:
case 203:
case 206: