proxy.golang.org : github.com/cespare/hmux
Package hmux provides an HTTP request multiplexer which matches requests to handlers using method- and path-based rules. Using hmux involves two phases: construction, using a Builder, and request serving, using a Mux. Builder rules match methods and paths in request URLs. The path is matched using a pattern string. A pattern begins with a slash ("/") and contains zero or more segments separated by slashes. In the simplest case, the pattern matches a single route because each segment is a literal string: A pattern segment may instead contain a parameter, which begins with a colon: This pattern matches many different URL paths: A pattern may end with a slash; it only matches URL paths that also end with a slash. A "wildcard" pattern has a segment containing only * at the end (after the final slash): This matches any path beginning with the same prefix of segments: Wildcard patterns are especially useful in conjunction with Builder.Prefix and Builder.ServeFS, which always treat their inputs as wildcard patterns even if they don't have the ending *. There are two special patterns which don't begin with a slash: "*" and "". The pattern "*" matches (only) the request URL "*". This is typically used with OPTIONS requests. The empty pattern ("") matches any request URL. A Builder does not accept two rules with overlapping methods and the same pattern. To avoid confusion, apart from wildcard patterns and the special pattern "*", asterisks are not allowed in patterns. Additionally, a pattern segment cannot be empty. Literal pattern segments are interpeted as URL-escaped strings. Therefore, to create a pattern which matches a path containing characters reserved for pattern syntax, URL-encode those characters. A Mux routes requests to the handler registered by the most specific rule that matches the request's path and method. When comparing two rules, the most specific one is the rule with the most specific pattern; if both rules have patterns that are equally specific, then the most specific rule is the one that matches specific methods rather than all methods. Pattern specificity is defined as a segment-by-segment comparison, starting from the beginning. The types of segments, arranged from most to least specific, are: For two patterns having the same segment specificity, a pattern ending with slash is more specific than a pattern ending with a wildcard. As an example, suppose there are five rules: Requests are routed as follows: If a request matches the patterns of one or more rules but does not match the methods of any of those rules, the Mux writes an HTTP 405 ("Method Not Allowed") response with an Allow header that lists all of the matching methods. If there is no matching rule pattern at all, the Mux writes an HTTP 404 ("Not Found") response. Before routing, if the request path contains any segment that is "" (that is, a double slash), ".", or "..", the Mux writes an HTTP 308 redirect to an equivalent cleaned path. For example, all of these are redirected to /x/y: This automatic redirection does not apply to CONNECT requests. Pattern segments may specify a type after a second colon: A string parameter matches any URL path segment, and it is also the default type if no parameter type is given. The other parameter types are int32 and int64. A pattern segment with an integer type matches the corresponding request URL path segment if that segment can be parsed as a decimal integer of that type. Parameters are passed to HTTP handlers using http.Request.Context. Inside an HTTP handler called by a Mux, parameters are available via RequestParams.
Registry
-
Source
- Documentation
- JSON
purl: pkg:golang/github.com/cespare/hmux
License: MIT
Latest release: 8 months ago
First release: over 3 years ago
Namespace: github.com/cespare
Dependent repositories: 1
Stars: 2 on GitHub
Forks: 0 on GitHub
See more repository details: repos.ecosyste.ms
Last synced: 11 days ago