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 ;
5 { t } [ [ \ + first ] [ <500> ] recover response? ] unit-test
7 { "text/plain; charset=ASCII" } [
9 "text/plain" >>content-type
10 "ASCII" >>content-charset
14 { "text/xml; charset=UTF-8" } [
16 "text/xml" >>content-type
22 "image/jpeg" >>content-type
26 { "application/octet-stream" } [
31 ! RFC 2616: Section 19.3
32 ! The line terminator for message-header fields is the sequence CRLF.
33 ! However, we recommend that applications, when parsing such headers,
34 ! recognize a single LF as a line terminator and ignore the leading CR.
39 "host: 127.0.0.1:55532"
40 "user-agent: Factor http.client"
41 } [ join-lines ] [ "\r\n" join ] bi
42 [ [ read-request ] with-string-reader ] same?
45 ! RFC 2616: Section 4.1
46 ! In the interest of robustness, servers SHOULD ignore any empty
47 ! line(s) received where a Request-Line is expected. In other words, if
48 ! the server is reading the protocol stream at the beginning of a
49 ! message and receives a CRLF first, it should ignore the CRLF.
61 "\r\n\r\n\r\nGET / HTTP/1.0\r\n\r\n"
62 [ read-request ] with-string-reader
65 ! RFC 1945; Section 4.1
66 ! Implement a version of Simple-Request, although rather than
67 ! parse version 0.9, we parse 1.0 to return a Full-Response.
79 "\r\n\r\n\r\nGET /\r\n\r\n"
80 [ read-request ] with-string-reader
83 ! Don't rethrow parse-errors with an empty request string. They are
84 ! expected from certain browsers when the server serves a certificate
85 ! that the browser can't verify.
87 0 "" f <parse-error> \ bad-request-line boa handle-client-error
91 0 "not empty" f <parse-error> handle-client-error
92 ] [ parse-error? ] must-fail-with