From 9aec30557bb05a021fccebd497c2d62e758f317e Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Wed, 12 Sep 2018 09:20:40 +0200 Subject: [PATCH] MEDIUM: h1: consider err_pos before deciding to accept a header name or not Till now the H1 parser made for H2 used to be lenient on invalid header field names because they were supposed to be produced by haproxy. Now instead we'll rely on err_pos to know how to act (ie: -2 == must block). --- src/h1.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/src/h1.c b/src/h1.c index 63f284ee3..20a14934d 100644 --- a/src/h1.c +++ b/src/h1.c @@ -864,16 +864,15 @@ int h1_headers_to_hdr_list(char *start, const char *stop, EAT_AND_JUMP_OR_RETURN(ptr, end, http_msg_hdr_l1_sp, http_msg_ood, state, H1_MSG_HDR_L1_SP); } - if (HTTP_IS_LWS(*ptr)) { + if (likely(h1m->err_pos < -1) || *ptr == '\n') { state = H1_MSG_HDR_NAME; goto http_msg_invalid; } - /* now we have a non-token character in the header field name, - * it's up to the H1 layer to have decided whether or not it - * was acceptable. If we find it here, it was considered - * acceptable due to configuration rules so we obey. - */ + if (h1m->err_pos == -1) /* capture the error pointer */ + h1m->err_pos = ptr - start + skip; /* >= 0 now */ + + /* and we still accept this non-token character */ EAT_AND_JUMP_OR_RETURN(ptr, end, http_msg_hdr_name, http_msg_ood, state, H1_MSG_HDR_NAME); case H1_MSG_HDR_L1_SP: