GetStatusCode.com/100 will always return a 100 HTTP Status Code. That is by design.
This means that the server has received the request headers, and that the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). If the request body is large, sending it to a server when a request has already been rejected based upon inappropriate headers is inefficient. To have a server check if the request could be accepted based on the request's headers alone, a client must send Expect: 100-continue as a header in its initial request and check if a 100 Continue status code is received in response before continuing (or receive 417 Expectation Failed and not continue).
For easy reference, some of the details of your request have been included below.
This is a tool that I built just to give me an easy way to test scripts that need to handle a variety of http status codes. Even if I'm not integrating with a REST API or other web service that might present a variety of status codes, I often still need to gracefully handle the occasional unexpected 500 error. Short of deliberately coding a glitch (which is only an option if I'm in control of the remote end, which isn't always the case), it's hard to test this. So, I wrote this handy site that responds with the appropriate header for the major codes.
Whether you want to test code like I often do or just see an example 100 http status code, this is a handy tool to use. Plus, it offers some basic information that I occasionally need as well, like IP geolocation (and it even uses HTML5 geolocation to tell how far off they are from each other) and user agent parsing for browser and operating system.
This tool is free to use, but you should be mindful of its limitations. It does not fully and properly implement the HTTP specification (it's not RESTful in the slightest). It only spits out this page (roughly, with some variation by code requested) and the associated HTTP status code headers. My scripts key off those response headers (as do most frameworks I've dealt with), so that's sufficient to test. But if you're expecting a 301 to actually include a Location header, you won't find it here.
If you appreciate this tool, feel free to link to it, share it on Facebook, and the like. The more people use this, the more I can justify adding features.
|Bremen||03||DE||498 Token expired/invalid (Esri)|
|Ashburn||VA||US||207 Multi-Status (WebDAV; RFC 4918)|
|Ashburn||VA||US||507 Insufficient Storage (WebDAV; RFC 4918)|
|Ashburn||VA||US||419 Authentication Timeout (not in RFC 2616)|
|Ashburn||VA||US||429 Too Many Requests (RFC 6585)|