package httpguts Import Path vendor/golang.org/x/net/http/httpguts (on golang.org and go.dev) Dependency Relation imports 5 packages, and imported by 4 packages Involved Source Files d-> guts.go httplex.go Exported Valuesfunc HeaderValuesContainsToken(values string, token string) bool HeaderValuesContainsToken reports whether any string in values contains the provided token, ASCII case-insensitively.func PunycodeHostPort(v string) (string, error) PunycodeHostPort returns the IDNA Punycode version of the provided "host" or "host:port" string.func ValidHeaderFieldName(v string) bool ValidHeaderFieldName reports whether v is a valid HTTP/1.x header name. HTTP/2 imposes the additional restriction that uppercase ASCII letters are not allowed. RFC 7230 says: header-field = field-name ":" OWS field-value OWS field-name = token token = 1*tchar tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHAfunc ValidHeaderFieldValue(v string) bool ValidHeaderFieldValue reports whether v is a valid "field-value" according to http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 : message-header = field-name ":" [ field-value ] field-value = *( field-content | LWS ) field-content = <the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, separators, and quoted-string> http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2 : TEXT = <any OCTET except CTLs, but including LWS> LWS = [CRLF] 1*( SP | HT ) CTL = <any US-ASCII control character (octets 0 - 31) and DEL (127)> RFC 7230 says: field-value = *( field-content / obs-fold ) obj-fold = N/A to http2, and deprecated field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] field-vchar = VCHAR / obs-text obs-text = %x80-FF VCHAR = "any visible [USASCII] character" http2 further says: "Similarly, HTTP/2 allows header field values that are not valid. While most of the values that can be encoded will not alter header field parsing, carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the zero character (NUL, ASCII 0x0) might be exploited by an attacker if they are translated verbatim. Any request or response that contains a character not permitted in a header field value MUST be treated as malformed (Section 126.96.36.199). Valid characters are defined by the field-content ABNF rule in Section 3.2 of [RFC7230]." This function does not (yet?) properly handle the rejection of strings that begin or end with SP or HTAB.
|The pages are generated with Golds v0.1.7. (GOOS=linux GOARCH=amd64) Golds is a Go 101 project and developed by Tapir Liu. PR and bug reports are welcome and can be submitted to the issue list. Please follow @Go100and1 (reachable from the left QR code) to get the latest news of Golds.|