risk is moderate. Only ever enable this with known clients if absolutely
needed.
+ - "short-status-code" (response): this controls acceptance of status codes
+ shorter than 3 characters (e.g. "0" or "99"). A lazy regex-based parser
+ in a client may get confused. The risk is low. Only ever enable this with
+ known clients if really needed.
+
- "non-token-in-header-name" (both): this controls the acceptance of
forbidden characters in header field names. It is often used to adapt to
internally developed non-standard applications which use forbidden
HTTP_VIO_URL_FRAG = 0, // fragment in url ('#')
HTTP_VIO_URL_NON_ASCII, // non-ASCII (>=128) in URL
HTTP_VIO_STATUS_LONG, // status longer than 3 characters
+ HTTP_VIO_STATUS_SHORT, // status shorter than 3 characters
HTTP_VIO_HDR_NAME_NON_TOK, // non-token in header name
HTTP_VIO_HDR_VALUE_NUL, // NUL byte in header value
HTTP_VIO_TE_BAD, // inconsistent transfer encoding
if (likely(HTTP_IS_SPHT(*ptr))) {
sl.st.c.len = ptr - sl.st.c.ptr;
+ if (sl.st.c.len < 3) {
+ /* less than 3 digits */
+ if (h1m->err_pos < -1 || !(global.acc_hres_vio & (1U << HTTP_VIO_STATUS_SHORT))) {
+ state = H1_MSG_RPCODE;
+ goto http_msg_invalid;
+ } else if (h1m->err_pos == -1) {
+ /* only capture the error pointer */
+ h1m->err_pos = ptr - start + skip;
+ }
+ }
EAT_AND_JUMP_OR_RETURN(ptr, end, http_msg_rpcode_sp, http_msg_ood, state, H1_MSG_RPCODE_SP);
}
{ "fragment-in-url", HTTP_VIO_URL_FRAG, HTTP_DIR_REQ },
{ "non-ascii-in-url", HTTP_VIO_URL_NON_ASCII, HTTP_DIR_REQ },
{ "long-status-code", HTTP_VIO_STATUS_LONG, HTTP_DIR_RES },
+ { "short-status-code", HTTP_VIO_STATUS_SHORT, HTTP_DIR_RES },
{ "non-token-in-header-name", HTTP_VIO_HDR_NAME_NON_TOK, HTTP_DIR_BOTH },
{ "nul-in-header-value", HTTP_VIO_HDR_VALUE_NUL, HTTP_DIR_BOTH },
{ "inconsistent-transfer-encoding", HTTP_VIO_TE_BAD, HTTP_DIR_RES },