This site was very helpful when I refractored a program from using libcurl to cpprest. I used it to make sure the sent http request headers where exactly the same.
I'll remember that next time. I been using fiddler to see websites http traffic which is helpful. But my programs http traffic doesn't show up there.. So ill try wireshark next time.
Besides, 1223 isn't specified by the HTTP RFCs, nor is it returned anywhere except from a library call in a buggy library. I'd say it's not appropriate for an HTTP testing service to support 1223.
interestingly, i believe your sample code would, in all but the latest version of Rails, leave someone open to some of the Rails CVEs that just got announced yesterday :)
For local testing I often run pathod (http://pathod.net/), which can not only yield arbitrary response codes based on the request URL, but randomly generated headers and body and even timeouts.
Weird, it doesn't implement "HTTP 451 Unavailable For Legal Reasons" or "HTTP 420 DAB Session". It also doesn't return an Allow: header for 405. It also doesn't return 100-103.
Instead of specifying the requested HTTP code in the URL path, I put the requested HTTP code in the URL query, basically ignoring the URL path. In that way, the URL path -- the resource identification in a REST-styled API -- can stay whatever you want as you're specifying the requested status code as query parameter. This made testing a program that uses resources in a REST API easier, as I don't need to rewrite the URL path, but just require to add a query parameter in my test code.
Oh, and also other request types are specified in the URL query, such as a delayed response: http://example.com/resource/id?delay=0.5, which returns a 200 after 0.5 seconds.
While that list is handy for sure, the OP's site also enables you to actually get the HTTP status code of your desires, since you can specify it in the request URL path: http://codes.io/304. This will return a `304 Not Modified` response, which can be helpful in writing testcode for your API service.
46 comments
[ 4.3 ms ] story [ 88.1 ms ] threadPlease support “451 Unavailable for legal reasons”.
http://www.451unavailable.org/
https://en.wikipedia.org/wiki/HTTP_451
http://httpstat.us/451
Charles has a fairly neat way of making it all work.
http://codes.io/1223 -> 503
Besides, 1223 isn't specified by the HTTP RFCs, nor is it returned anywhere except from a library call in a buggy library. I'd say it's not appropriate for an HTTP testing service to support 1223.
rails would be
Examples: https://http.cat/418 - https://http.cat/451
https://httpstatuses.com/
or by individual code..
https://httpstatuses.com/200 https://httpstatuses.com/201 https://httpstatuses.com/404 https://httpstatuses.com/418
I opened an issue for that: https://github.com/SnootyMonkey/posthere.io/issues/4
I also made a "return the HTTP code you request"-service like this, but with another design choice than in this one and some others like http://httpbin.org/, https://httpstatuses.com/, http://httpstat.us/.
Instead of specifying the requested HTTP code in the URL path, I put the requested HTTP code in the URL query, basically ignoring the URL path. In that way, the URL path -- the resource identification in a REST-styled API -- can stay whatever you want as you're specifying the requested status code as query parameter. This made testing a program that uses resources in a REST API easier, as I don't need to rewrite the URL path, but just require to add a query parameter in my test code.
Example: instead of http://example.com/404 I request http://example.com/resource/id?response=404 to get a 404 response. http://example.com/resource/another-id?response=200 gets a 200 code.
In this way, combining requested responses is also possible: http://example.com/resource/id?status=500&delay=2 to return a 500 after 2 seconds.
I couldn't figure out if this behavior is also possible with services specifying the desired responses in the URL path.
An error occurred in the application and your page could not be served. Please try again in a few moments.
If you are the application owner, check your logs for details."
$ curl -i codes.io/600
HTTP/1.1 -424 ???
...