Hacker News new | past | comments | ask | show | jobs | submit login
Whatever you set the URL to, that HTTP code will be returned (codes.io)
136 points by ca98am79 on Jan 26, 2016 | hide | past | favorite | 44 comments





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.


You could have just looked at the traffic directly with wireshark rather than trust an external site.


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.


I think this might not be possible for SSL/TLS traffic, without some kind of MITM.


It is possible with SSL/TLS traffice: you need to supply private key to WireShark, so it will be able to decode conversation.


Most dev 'MITM' proxy tools have a way to inspect HTTPS by creating a new key and adding it to your systems trust.

Charles has a fairly neat way of making it all work.


Can second that, httpbin is a great resource!



Thanks for that. Did not know this existed.


Neat idea.

Please support “451 Unavailable for legal reasons”.

http://www.451unavailable.org/

https://en.wikipedia.org/wiki/HTTP_451



Looks like a similar utility supports it:

http://httpstat.us/451



On another note, if you want a swell compilation and explanation of every HTTP status code:

https://httpstatuses.com/

or by individual code..

https://httpstatuses.com/200 https://httpstatuses.com/201 https://httpstatuses.com/404 https://httpstatuses.com/418


Interesting, seems like the upcoming "Hello World" for API services :-)

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.


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.

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.


Unfortunately it just returns the code, not a compliant response (e.g., 405 should return an Allow: header).


This is my go-to resource for looking up status codes: https://http.cat/

Examples: https://http.cat/418 - https://http.cat/451



Input validation needed. http://codes.io/12345 returns " Application Error

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."


Here's one you can run yourself, if you want: https://github.com/bmhatfield/httpecho


http://posthere.io/ is also OSS and you can run it yourself if you want.



Anything unexpected returns 503. Try http://codes.io/404/ (notice the ending /)

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.


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.


https://posthere.io/ implements 451, 420 and 100-103. It also doesn't return an Allow: header for 405.

I opened an issue for that: https://github.com/SnootyMonkey/posthere.io/issues/4


Awesome!


Not sure if I'm missing the purpose of this site, but why not just print off this list and refer to it when writing code: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes


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.


Interesting. I noticed it is built on Heroku platform. What specific stack did you use to implement this?


you could use pretty much anything.

rails would be

    def status
      render(text: params[:status], status: params[:status])
    end


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 :)


100 doesn't work (it returns 503)


Seems none of the 1xx series are expected by the service. Anything unexpected returns 503. Try adding a / at the end of one that does work.



Can you print the text in the body of the result? Not just the code.


418 Works...


So? It's valid, isn't it? "I'm a teapot"?



Huh?

$ curl -i codes.io/600

HTTP/1.1 -424 ???

...


We have reached peak HN.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: