HTTP Viewer makes it really easy to view any HTTP responses from a remote server. Just put the URL you want to test in the URL section and you will be ready to go! The URLs can begin with either http:// or https:// since this tool can view the connections of secure servers.
The Verb section will allow you to select which sort of HTTP request you want to send. There are several possible methods, but for practical purposes, we allow GET, HEAD, TRACE, and POST.
GET will request a file from a remote server.
HEAD will only request the information (or header) of a file without actually sending the file itself, which is often used by browsers and bots to determine if they should use a version of that file that they have previously downloaded and saved in their local caches or if they should spend time redownloading the file again.
TRACE will request the server to send back the request that you have sent to it so you can see if there are any problems with your HTTP request. This can be useful for debugging purposes, though many servers have this method disabled or restricted.
POST is used to send data such as messages and other user input to a remote server. However, because the data that is sent can be of just about anything and interpreted in any way by the server (and since there is no option to include any actual data with this tool), POST is here for potential debugging purposes.
The Version option lets you choose between using the HTTP/1.0 and HTTP/1.1 protocols. While version 1.1 is common among HTTP servers, 1.0 is also offered for flexibility to test connections that are started by older software. You may notice that when HTTP/1.0 is selected, the Accept Encoding box is grayed out. This is because version 1.0 of the HTTP protocol does not allow Accept Encoding; this feature was introduced in v1.1.
The Output option lets you choose how you want to view the body of the message returned by the remote server.
Text will return the message in a straightforward way, letting you see it just the way it is transferred. Newlines and carriage returns are shown and emphasized with \n and \r respectively. This visualization of these otherwise-invisible characters makes it easy for developers to find problems with these breaks and returns.
Hexadecimal, on the other hand, will display the contents of the HTTP return in hex values broken into rows of 16 characters, much like how you would view a file with any standard hex editor. This mode makes it easier to read binary files or to read different components of a remote file's header.
The Referer [sic] option lets you tell the remote server what page you are coming from. This field can be edited for debugging and testing purposes.
Accept Encoding lets you specify how you prefer your content to be encoded when it is sent to you. Common encodings include things like gzip, deflate which would tell the server to compress the data using either the gzip or deflate compression methods before sending it. This can be useful for determining whether or not a remote server supports various transfer encodings or whether or not they are encoding the files properly.
The User Agent dropdown box lets you choose what kind of browser you want to identify as in your HTTP request. Some servers may return alternate versions of their sites based on what browser is being identified.
When you submit a URL to HTTP Viewer, you will often see three sections returned: HTTP Request, HTTP Reponse Header, and HTTP Response Body.
The HTTP Request shows you the exact data being sent to the remote server. This data includes the type of request that you're making as well as the ways you want the server to respond.
The Reponse Header is the beginning of the HTTP response which contains information about the server and of the contents that are being returned. Common information includes the HTTP status (or how the server responded to your request: 200 means that the request was successful, 403 means that the request was forbidden or restricted from being carried out, etc), the server's name, and the date and time that the request was responded to.
The Reponse Body is everything that comes after the header. This is often the file that you have requested from the remote server in its entirety. Commonly, this will be an HTML document, but it can be anything, such as an image, Flash animation, or anything else. If you have requested something like an image and the body is a garbled mess of characters, set the Output option to display in Hexadecimal to hopefully make some more sense out of the file's data.