If http_handler @config is a dbref of a valid player, SharpMUSH will support HTTP requests reaching its mush port. It is very low level, and a little tricky to understand.
If an HTTP Handler isn’t set, or a given method attribute doesn’t exist on the http handler object, Penn will default to responding with mud_url or an error page.
@config http_per_second must also be a postive number to enable HTTP commands, and they will be limited by that amount.
When an HTTP request hits the SharpMUSH port, SharpMUSH invisibly logs in to the HTTP Handler player (@config http_handler), and executes an @include me/<method>. e.g: `@include me/get`.
Immediately when the @include finishes, the http request is complete. Any queued entries (such as @wait, $-commands, etc) are not going to be sent to the HTTP client - you’ll need to code using @include, /inline switches, and the like.
%0 will be the pathname, e.g: ”/”, “/path/to”, “/foo?bar=baz”, etc.
%1 will be the body of the request. If it’s json, use json_query to deal with it. If it’s form-encoded, look at formdecode()
Anything sent to the HTTP Handler player during evaluation of this code is included in the body sent to the HTTP Client. There is a maximum size of BUFFER_LEN for the body of the response.
To modify the response headers, use the command @respond
See Also
[http2]
HTTP2
To use SharpMUSH HTTP Handler:
> @pcreate HTTPHandler
> @config/set http_handler=[num(*HTTPHandler)]
> &GET *HTTPHandler=say Somebody tried to HTTP GET %0!
You will very likely want to set the http_handler option in your mush.cnf file to ensure it survives over reboots and is actively receiving events even during startup.
By default, SharpMUSH will respond with a 404 NOT FOUND. You will need to use @respond to control what is sent to the client.
See Also
[- [http examples]
[http sitelock]
[event http]
See Also
[http3]
HTTP3
HTTP connections to SharpMUSH are limited to BUFFER_LEN in header and body size.
Incoming headers will be set in Q-registers: %q contains a list of all headers by name. Individual headers will be set in %q<hdr.name>, prefixed with hdr. e.g: %q<hdr.host> to obtain the value to the Host: header. Or %q<hdr.Cookie> for Cookies.
Multiple header lines will be added to the same q-register name, but %r-delimited. So two “Cookie:” lines becomes %q with two %r-delimited lines.
HTTP Responses are limited to BUFFER_LEN in response size. Anything sent to the HTTPHandler player, whether it uses think or is @pemitted, is added to the response buffer.
Within the context of an HTTP Player connection, @respond is used to modify the headers sent back to the HTTP client.
If an attribute exists, Penn defaults to 200 OK, and Content-Type “text/plain”
@respond <code> <text> changes the 1st line sent to the client (200 OK)
@respond/type <text> replaces the current Content-Type header. (text/plain)
@respond/header <name>=<value> adds a new Header. This can’t be undone, as it’s appended to a buffer. So you can add multiple headers w/ same name.
@respond commands are not required to be run before any output is sent to the player. For Content-Length purposes, Penn buffers all output before the @include finishes.
If @respond is run outside of an HTTP Context, the enactor will see “(HTTP): …” for debugging, but it isn’t buffered for output as if it was an active http request.
Note: @respond/type is not syntactic sugar for `@respond/header Content-Type`. An HTTP @respond typically should only have one content-type, and @respond/type overrides it. Using @respond/header to add Content-Type will create a second header named Content-Type.
Adding a Content-Length header is not allowed - SharpMUSH calculates it from the output before sending.
@RESPOND3
To vaguely comply with most HTTP requirements:
@respond <code> <text>
must be 3 digits, followed by a space, then printable ascii text
Total length must be < 40 characters
This will be prepended by HTTP/1.1 when sent back to the client
@respond/header <name>: <value>
must be printable ascii characters (No accents, no %r)
must be printable, but accents allowed (No %r)
@respond/type <ctype>
should be alphanumeric, +, ., /, -. HTTP/1.1 does allow for parameters (text/plain; content-encoding=…), so we don’t enforce anything at present except printability().
FORMDECODE()
formdecode(<string>[, <paramname>[, <osep>]])
formdecode() is intended for use with the HTTP Handler. See [http] for more.
formdecode() converts form-encoded data, such as HTTP GET paths (after the ?) or the contents of POST with form-urlencoded data. It searches for the parameter named and returns with its decoded value.
If is not given, formdecode() returns a list of parameter names.
If there are multiple values, they will be separated by (default %b)
formdecode() requires libcurl (@http) to be enabled.
You can configure what paths and IPs you want to limit access to via @sitelock.
HTTP Requests will check @sitelock for IP restrictions and path restrictions for the config(http_handler) player. Right now, we don’t resolve hosts before HTTP connections are handled due to the time delay, but that may be an option in the future.
For path restrictions, @sitelock checks the pattern ”``”
Both IP and the “IP`Method`Path” approach check for “connect” option.
Examples:
Ban everybody using IP Address pattern matching 12.34.. from using HTTP:
