1 USING: accessors assocs continuations http http.server
2 http.server.requests io.encodings.utf8 io.encodings.binary
3 io.streams.string kernel math peg sequences tools.test urls
6 { t } [ [ \ + first ] [ <500> ] recover response? ] unit-test
8 { "text/plain; charset=ASCII" } [
10 "text/plain" >>content-type
11 "ASCII" >>content-charset
15 { "text/xml; charset=UTF-8" } [
17 "text/xml" >>content-type
23 "image/jpeg" >>content-type
27 { "application/octet-stream" } [
32 ! RFC 2616: Section 19.3
33 ! The line terminator for message-header fields is the sequence CRLF.
34 ! However, we recommend that applications, when parsing such headers,
35 ! recognize a single LF as a line terminator and ignore the leading CR.
40 "host: 127.0.0.1:55532"
41 "user-agent: Factor http.client"
42 } [ join-lines ] [ "\r\n" join ] bi
43 [ [ read-request ] with-string-reader ] same?
46 ! RFC 2616: Section 4.1
47 ! In the interest of robustness, servers SHOULD ignore any empty
48 ! line(s) received where a Request-Line is expected. In other words, if
49 ! the server is reading the protocol stream at the beginning of a
50 ! message and receives a CRLF first, it should ignore the CRLF.
62 "\r\n\r\n\r\nGET / HTTP/1.0\r\n\r\n"
63 [ read-request ] with-string-reader
66 ! RFC 1945; Section 4.1
67 ! Implement a version of Simple-Request, although rather than
68 ! parse version 0.9, we parse 1.0 to return a Full-Response.
80 "\r\n\r\n\r\nGET /\r\n\r\n"
81 [ read-request ] with-string-reader
84 ! Don't rethrow parse-errors with an empty request string. They are
85 ! expected from certain browsers when the server serves a certificate
86 ! that the browser can't verify.
88 0 "" f <parse-error> \ bad-request-line boa handle-client-error
92 0 "not empty" f <parse-error> handle-client-error
93 ] [ parse-error? ] must-fail-with