PDF(7.8 KB) View with Adobe Reader on a variety of devices
Updated:August 12, 2014
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
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.
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.
2xx codes: Successful
200 OK: The most common response code. This signifies that the request is successful 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.
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.
307 Temporary Redirect: For all intents and purposes, it has the same meaning as the 302. If further details are discovered, this article can be updated.
4xx codes: Client Error
400 Bad Request: This means the something in the HTTP request is not following correct syntax. Possible causes could be due to multiple headers being on the same line, spaces in a header, no HTTP/1.1 in the URI, so forth. RFC 2616 should be referenced for proper syntax.
401 Unauthorized: The object requested requires authentication in order to be accessed. The 401 is used for authentication to a destination web server. When using the Cisco Web Security appliance (WSA) in transparent mode, a 401 is sent back to the client when authentication is enabled on the proxy. This is because the appliance is spoofing itself as if it were the OCS (origin content server).
The available methods of authentication are specified in a www-authenticate: HTTP response header. This will tell the client whether or not this server is asking for NTLM, basic, or other methods of authentication.
403 Forbidden: The client is denied from accessing the requested object. There are many causes for why a server may deny access to an object. Typically, the server will include some sort of description of the cause within the HTTP data (HTML response).
404 Not Found: The requested object does not exist on the server.
407 Proxy Authentication Required: This is the same as a 401, except that it is specifically for authentication to a proxy, not the OCS. This is sent only if the request was sent explicitly to the proxy. A 407 cannot be sent to a client while using WSA as transparent proxy, as the client does not know the proxy exists. If this is the case, the client will most likely FIN or RST the TCP socket.
Instead of using www-authenticate: headers to specify what authentication methods are available, the proxy-authenticate: header is used.
5xx codes: Server Error
500 Internal Server Error: Generic server failure
502 Bad Gateway: You will typically see this when using the WSA as a proxy, where the gateway is responding incorrectly.
503 Service Unavailable: This is typically sent when the OCS is being over encumbered. Attempting the request again at a later time should be successful.
504 Gateway Timeout: A 504 will be sent if WSA did not receive a response from its gateway.