Cisco Cisco Web Security Appliance S360 Troubleshooting Guide
What do the different HTTP response codes mean?
Document ID: 118217
Contributed by Josh Wolfer and Siddharth Rajpathak, Cisco TAC
Engineers.
Engineers.
Aug 12, 2014
Contents
Question:
Question:
What do the different HTTP response codes mean?
Environment: Cisco Web Security appliance (WSA) running any AsyncOS version
HTTP always has a client request and a server response. The server responses are classified by a numerical
response code. Response codes indicate the reasons behind successful and failed HTTP requests.
response code. Response codes indicate the reasons behind successful and failed HTTP requests.
For full detailed information regarding HTTP response codes, please see RFC 2616 (HTTP), section 10.
Below are details regarding the most common response code that you are likely to run into:
1xx codes: Informational
100 Continue: Typically seen in regards to the ICAP protocol. This is an informational
response that let's the client know that it can continue to send data. In regards to ICAP
services (such as virus scanning), the server may only want to see first x amount of bytes.
When it is done scanning the first set of bytes and did not detect a virus, it will send a 100
Continue to let the client know to send the rest of the object.
response that let's the client know that it can continue to send data. In regards to ICAP
services (such as virus scanning), the server may only want to see first x amount of bytes.
When it is done scanning the first set of bytes and did not detect a virus, it will send a 100
Continue to let the client know to send the rest of the object.
2xx codes: Successful
200 OK: The most common response code. This signifies that the request is successful
without any problems.
without any problems.
3xx codes: Redirection
302 Found: This is a temporary redirection. The client is instructed to make a new request for
the object specified in the Location: header.
the object specified in the Location: header.
304 Not Modified: This is in response to a GIMS (GET If−modified−since). This is literally a
standard HTTP GET that includes the header If−modified−since: <date>. This header tells the
server that the client has a copy of the requested object in it's local cache and included is the
date the object was fetched. If the object has been modified since that date, the server will
respond with a 200 OK and a fresh copy of the object. If the object has not changed since the
fetched date, the server will send back a 304 Not Modified response.
standard HTTP GET that includes the header If−modified−since: <date>. This header tells the
server that the client has a copy of the requested object in it's local cache and included is the
date the object was fetched. If the object has been modified since that date, the server will
respond with a 200 OK and a fresh copy of the object. If the object has not changed since the
fetched date, the server will send back a 304 Not Modified response.