Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
httpstatus : bash script to get HTTP response code with optional status message (includes verbose definitions in comment)
#!/usr/bin/env bash
# bash 4.1.5(1) Linux Ubuntu 10.04 Date : 2011-08-25
#
# _______________| httpstatus : get HTTP status code
#
# Usage: httpstatus URL [timeout] [--code or --status] [see 4.]
# ^message with code (default)
# ^code (numeric only)
# ^in secs (default: 3)
# ^URL without "http://" prefix works fine.
#
# 4. curl options: e.g. use -L to follow redirects.
#
# Dependencies: curl
#
# Example: $ httpstatus bit.ly
# 301 Redirection: Moved Permanently
# CHANGE LOG
# 2011-08-25 Publicly available at https://gist.github.com/1171304
# Add timeout and status info. Restrict query to one URL.
# Add --no-keepalive to curl arguments.
# Did not adopt Andrew Gilmartin's suggestion, --head, where curl
# retreives only the HTTP-header, not the entire document
# (would seem faster, but does not always work; e.g. bit.ly).
#
# 2011-08-24 First version based on one-liner from Hilary Mason's script:
# http://www.hilarymason.com/blog/bash-get-http-response-codes-for-a-list-of-urls/
#
# # "I had a file with a list of URLs, and I wanted the
# # HTTP response codes for each of them." 2011-08-24 blog post
#
# while read line
# do
# echo $(curl --write-out %{http_code} --silent --output /dev/null $line)
# done <$1
# _____ Prelims
set -u
# ^ unbound (i.e. unassigned) variables shall be errors.
set -e
# ^ error checking :: Highly Recommended (caveat: you can't check $? later).
#
# _______________ :: BEGIN Script ::::::::::::::::::::::::::::::::::::::::
url=${1:-'http://www.google.com'}
timeout=${2:-'3'}
# ^in seconds
flag=${3:-'--status'}
# curl options, e.g. -L to follow redirects
arg4=${4:-''}
arg5=${5:-''}
arg6=${6:-''}
arg7=${7:-''}
curlops="$arg4 $arg5 $arg6 $arg7"
# __________ get the CODE which is numeric:
code=`echo $(curl --write-out %{http_code} --silent -S --connect-timeout $timeout \
--no-keepalive $curlops --output /dev/null $url)`
# though curl is --silent, -S will show its errors.
# __________ get the STATUS (from code) which is human interpretable:
case $code in
000) status="Not responding within $timeout seconds" ;;
100) status="Informational: Continue" ;;
101) status="Informational: Switching Protocols" ;;
200) status="Successful: OK within $timeout seconds" ;;
201) status="Successful: Created" ;;
202) status="Successful: Accepted" ;;
203) status="Successful: Non-Authoritative Information" ;;
204) status="Successful: No Content" ;;
205) status="Successful: Reset Content" ;;
206) status="Successful: Partial Content" ;;
300) status="Redirection: Multiple Choices" ;;
301) status="Redirection: Moved Permanently" ;;
302) status="Redirection: Found residing temporarily under different URI" ;;
303) status="Redirection: See Other" ;;
304) status="Redirection: Not Modified" ;;
305) status="Redirection: Use Proxy" ;;
306) status="Redirection: status not defined" ;;
307) status="Redirection: Temporary Redirect" ;;
400) status="Client Error: Bad Request" ;;
401) status="Client Error: Unauthorized" ;;
402) status="Client Error: Payment Required" ;;
403) status="Client Error: Forbidden" ;;
404) status="Client Error: Not Found" ;;
405) status="Client Error: Method Not Allowed" ;;
406) status="Client Error: Not Acceptable" ;;
407) status="Client Error: Proxy Authentication Required" ;;
408) status="Client Error: Request Timeout within $timeout seconds" ;;
409) status="Client Error: Conflict" ;;
410) status="Client Error: Gone" ;;
411) status="Client Error: Length Required" ;;
412) status="Client Error: Precondition Failed" ;;
413) status="Client Error: Request Entity Too Large" ;;
414) status="Client Error: Request-URI Too Long" ;;
415) status="Client Error: Unsupported Media Type" ;;
416) status="Client Error: Requested Range Not Satisfiable" ;;
417) status="Client Error: Expectation Failed" ;;
500) status="Server Error: Internal Server Error" ;;
501) status="Server Error: Not Implemented" ;;
502) status="Server Error: Bad Gateway" ;;
503) status="Server Error: Service Unavailable" ;;
504) status="Server Error: Gateway Timeout within $timeout seconds" ;;
505) status="Server Error: HTTP Version Not Supported" ;;
*) echo " !! httpstatus: status not defined." && exit 1 ;;
esac
# _______________ MAIN
case $flag in
--status) echo "$code $status" ;;
-s) echo "$code $status" ;;
--code) echo "$code" ;;
-c) echo "$code" ;;
*) echo " !! httpstatus: bad flag" && exit 1 ;;
esac
exit 0
# _______________ EOS :: END of Script ::::::::::::::::::::::::::::::::::::::::
# _______________ STATUS CODE DEFINITIONS
# Section 10, Hypertext Transfer Protocol -- HTTP/1.1
# RFC 2616 Fielding, et al.
#
# Each Status-Code is described below, including a description of which
# method(s) it can follow and any metainformation required in the response.
#
# __________ 10.1 Informational 1xx
#
# This class of status code indicates a provisional response, consisting only of
# the Status-Line and optional headers, and is terminated by an empty line.
# There are no required headers for this class of status code. Since HTTP/1.0
# did not define any 1xx status codes, servers MUST NOT send a 1xx response to
# an HTTP/1.0 client except under experimental conditions.
#
# A client MUST be prepared to accept one or more 1xx status responses prior to
# a regular response, even if the client does not expect a 100 (Continue) status
# message. Unexpected 1xx status responses MAY be ignored by a user agent.
#
# Proxies MUST forward 1xx responses, unless the connection between the proxy
# and its client has been closed, or unless the proxy itself requested the
# generation of the 1xx response. (For example, if a proxy adds a "Expect:
# 100-continue" field when it forwards a request, then it need not forward the
# corresponding 100 (Continue) response(s).)
#
# _____ 10.1.1 100 Continue
#
# The client SHOULD continue with its request. This interim response is used to
# inform the client that the initial part of the request has been received and
# has not yet been rejected by the server. The client SHOULD continue by sending
# the remainder of the request or, if the request has already been completed,
# ignore this response. The server MUST send a final response after the request
# has been completed. See section 8.2.3 for detailed discussion of the use and
# handling of this status code.
#
#
# _____ 10.1.2 101 Switching Protocols
#
# The server understands and is willing to comply with the client's request, via
# the Upgrade message header field (section 14.42), for a change in the
# application protocol being used on this connection. The server will switch
# protocols to those defined by the response's Upgrade header field immediately
# after the empty line which terminates the 101 response.
#
# The protocol SHOULD be switched only when it is advantageous to do so. For
# example, switching to a newer version of HTTP is advantageous over older
# versions, and switching to a real-time, synchronous protocol might be
# advantageous when delivering resources that use such features.
#
#
# __________ 10.2 Successful 2xx
#
# This class of status code indicates that the client's request was successfully
# received, understood, and accepted.
#
# _____ 10.2.1 200 OK
#
# The request has succeeded. The information returned with the response is
# dependent on the method used in the request, for example:
#
# GET an entity corresponding to the requested resource is sent in the response;
#
# HEAD the entity-header fields corresponding to the requested resource are sent
# in the response without any message-body;
#
# POST an entity describing or containing the result of the action;
#
# TRACE an entity containing the request message as received by the end server.
#
# _____ 10.2.2 201 Created
#
# The request has been fulfilled and resulted in a new resource being created.
# The newly created resource can be referenced by the URI(s) returned in the
# entity of the response, with the most specific URI for the resource given by a
# Location header field. The response SHOULD include an entity containing a list
# of resource characteristics and location(s) from which the user or user agent
# can choose the one most appropriate. The entity format is specified by the
# media type given in the Content-Type header field. The origin server MUST
# create the resource before returning the 201 status code. If the action cannot
# be carried out immediately, the server SHOULD respond with 202 (Accepted)
# response instead.
#
# A 201 response MAY contain an ETag response header field indicating the
# current value of the entity tag for the requested variant just created, see
# section 14.19.
#
# _____ 10.2.3 202 Accepted
#
# The request has been accepted for processing, but the processing has not been
# completed. The request might or might not eventually be acted upon, as it
# might be disallowed when processing actually takes place. There is no facility
# for re-sending a status code from an asynchronous operation such as this.
#
# The 202 response is intentionally non-committal. Its purpose is to allow a
# server to accept a request for some other process (perhaps a batch-oriented
# process that is only run once per day) without requiring that the user agent's
# connection to the server persist until the process is completed. The entity
# returned with this response SHOULD include an indication of the request's
# current status and either a pointer to a status monitor or some estimate of
# when the user can expect the request to be fulfilled.
#
# _____ 10.2.4 203 Non-Authoritative Information
#
# The returned metainformation in the entity-header is not the definitive set as
# available from the origin server, but is gathered from a local or a
# third-party copy. The set presented MAY be a subset or superset of the
# original version. For example, including local annotation information about
# the resource might result in a superset of the metainformation known by the
# origin server. Use of this response code is not required and is only
# appropriate when the response would otherwise be 200 (OK).
#
# _____ 10.2.5 204 No Content
#
# The server has fulfilled the request but does not need to return an
# entity-body, and might want to return updated metainformation. The response
# MAY include new or updated metainformation in the form of entity-headers,
# which if present SHOULD be associated with the requested variant.
#
# If the client is a user agent, it SHOULD NOT change its document view from
# that which caused the request to be sent. This response is primarily intended
# to allow input for actions to take place without causing a change to the user
# agent's active document view, although any new or updated metainformation
# SHOULD be applied to the document currently in the user agent's active view.
#
# The 204 response MUST NOT include a message-body, and thus is always
# terminated by the first empty line after the header fields.
#
# _____ 10.2.6 205 Reset Content
#
# The server has fulfilled the request and the user agent SHOULD reset the
# document view which caused the request to be sent. This response is primarily
# intended to allow input for actions to take place via user input, followed by
# a clearing of the form in which the input is given so that the user can easily
# initiate another input action. The response MUST NOT include an entity.
#
# _____ 10.2.7 206 Partial Content
#
# The server has fulfilled the partial GET request for the resource. The request
# MUST have included a Range header field (section 14.35) indicating the desired
# range, and MAY have included an If-Range header field (section 14.27) to make
# the request conditional.
#
# The response MUST include the following header fields:
#
# - Either a Content-Range header field (section 14.16) indicating
# the range included with this response, or a multipart/byteranges
# Content-Type including Content-Range fields for each part. If a
# Content-Length header field is present in the response, its
# value MUST match the actual number of OCTETs transmitted in the
# message-body.
#
# - Date
#
# - ETag and/or Content-Location, if the header would have been sent
# in a 200 response to the same request
#
# - Expires, Cache-Control, and/or Vary, if the field-value might
# differ from that sent in any previous response for the same
# variant
#
# If the 206 response is the result of an If-Range request that used a strong
# cache validator (see section 13.3.3), the response SHOULD NOT include other
# entity-headers. If the response is the result of an If-Range request that used
# a weak validator, the response MUST NOT include other entity-headers; this
# prevents inconsistencies between cached entity-bodies and updated headers.
# Otherwise, the response MUST include all of the entity-headers that would have
# been returned with a 200 (OK) response to the same request.
#
# A cache MUST NOT combine a 206 response with other previously cached content
# if the ETag or Last-Modified headers do not match exactly, see 13.5.4.
#
# A cache that does not support the Range and Content-Range headers MUST NOT
# cache 206 (Partial) responses.
#
# __________ 10.3 Redirection 3xx
#
# This class of status code indicates that further action needs to be taken by
# the user agent in order to fulfill the request. The action required MAY be
# carried out by the user agent without interaction with the user if and only if
# the method used in the second request is GET or HEAD. A client SHOULD detect
# infinite redirection loops, since such loops generate network traffic for each
# redirection.
#
# Note: previous versions of this specification recommended a maximum of
# five redirections. Content developers should be aware that there might
# be clients that implement such a fixed limitation.
#
# _____ 10.3.1 300 Multiple Choices
#
# The requested resource corresponds to any one of a set of representations,
# each with its own specific location, and agent- driven negotiation information
# (section 12) is being provided so that the user (or user agent) can select a
# preferred representation and redirect its request to that location.
#
# Unless it was a HEAD request, the response SHOULD include an entity containing
# a list of resource characteristics and location(s) from which the user or user
# agent can choose the one most appropriate. The entity format is specified by
# the media type given in the Content- Type header field. Depending upon the
# format and the capabilities of the user agent, selection of the most
# appropriate choice MAY be performed automatically. However, this specification
# does not define any standard for such automatic selection.
#
# If the server has a preferred choice of representation, it SHOULD include the
# specific URI for that representation in the Location field; user agents MAY
# use the Location field value for automatic redirection. This response is
# cacheable unless indicated otherwise.
#
# _____ 10.3.2 301 Moved Permanently
#
# The requested resource has been assigned a new permanent URI and any future
# references to this resource SHOULD use one of the returned URIs. Clients with
# link editing capabilities ought to automatically re-link references to the
# Request-URI to one or more of the new references returned by the server, where
# possible. This response is cacheable unless indicated otherwise.
#
# The new permanent URI SHOULD be given by the Location field in the response.
# Unless the request method was HEAD, the entity of the response SHOULD contain
# a short hypertext note with a hyperlink to the new URI(s).
#
# If the 301 status code is received in response to a request other than GET or
# HEAD, the user agent MUST NOT automatically redirect the request unless it can
# be confirmed by the user, since this might change the conditions under which
# the request was issued.
#
# Note: When automatically redirecting a POST request after receiving a
# 301 status code, some existing HTTP/1.0 user agents will erroneously
# change it into a GET request.
#
# _____ 10.3.3 302 Found
#
# The requested resource resides temporarily under a different URI. Since the
# redirection might be altered on occasion, the client SHOULD continue to use
# the Request-URI for future requests. This response is only cacheable if
# indicated by a Cache-Control or Expires header field.
#
# The temporary URI SHOULD be given by the Location field in the response.
# Unless the request method was HEAD, the entity of the response SHOULD contain
# a short hypertext note with a hyperlink to the new URI(s).
#
# If the 302 status code is received in response to a request other than GET or
# HEAD, the user agent MUST NOT automatically redirect the request unless it can
# be confirmed by the user, since this might change the conditions under which
# the request was issued.
#
# Note: RFC 1945 and RFC 2068 specify that the client is not allowed to
# change the method on the redirected request. However, most existing
# user agent implementations treat 302 as if it were a 303 response,
# performing a GET on the Location field-value regardless of the original
# request method. The status codes 303 and 307 have been added for servers
# that wish to make unambiguously clear which kind of reaction is expected
# of the client.
#
# _____ 10.3.4 303 See Other
#
# The response to the request can be found under a different URI and SHOULD be
# retrieved using a GET method on that resource. This method exists primarily to
# allow the output of a POST-activated script to redirect the user agent to a
# selected resource. The new URI is not a substitute reference for the
# originally requested resource. The 303 response MUST NOT be cached, but the
# response to the second (redirected) request might be cacheable.
#
# The different URI SHOULD be given by the Location field in the response.
# Unless the request method was HEAD, the entity of the response SHOULD contain
# a short hypertext note with a hyperlink to the new URI(s).
#
# Note: Many pre-HTTP/1.1 user agents do not understand the 303 status.
# When interoperability with such clients is a concern, the 302 status
# code may be used instead, since most user agents react to a 302 response
# as described here for 303.
#
# _____ 10.3.5 304 Not Modified
#
# If the client has performed a conditional GET request and access is allowed,
# but the document has not been modified, the server SHOULD respond with this
# status code. The 304 response MUST NOT contain a message-body, and thus is
# always terminated by the first empty line after the header fields.
#
# The response MUST include the following header fields:
#
# - Date, unless its omission is required by section 14.18.1
#
# If a clockless origin server obeys these rules, and proxies and clients add
# their own Date to any response received without one (as already specified by
# [RFC 2068], section 14.19), caches will operate correctly.
#
# - ETag and/or Content-Location, if the header would have been sent
# in a 200 response to the same request
#
# - Expires, Cache-Control, and/or Vary, if the field-value might
# differ from that sent in any previous response for the same
# variant
#
# If the conditional GET used a strong cache validator (see section 13.3.3), the
# response SHOULD NOT include other entity-headers. Otherwise (i.e., the
# conditional GET used a weak validator), the response MUST NOT include other
# entity-headers; this prevents inconsistencies between cached entity-bodies and
# updated headers.
#
# If a 304 response indicates an entity not currently cached, then the cache
# MUST disregard the response and repeat the request without the conditional.
#
# If a cache uses a received 304 response to update a cache entry, the cache
# MUST update the entry to reflect any new field values given in the response.
#
# _____ 10.3.6 305 Use Proxy
#
# The requested resource MUST be accessed through the proxy given by the
# Location field. The Location field gives the URI of the proxy. The recipient
# is expected to repeat this single request via the proxy. 305 responses MUST
# only be generated by origin servers.
#
# Note: RFC 2068 was not clear that 305 was intended to redirect a single
# request, and to be generated by origin servers only. Not observing
# these limitations has significant security consequences.
#
# _____ 10.3.7 306 (Unused)
#
# The 306 status code was used in a previous version of the specification, is no
# longer used, and the code is reserved.
#
# _____ 10.3.8 307 Temporary Redirect
#
# The requested resource resides temporarily under a different URI. Since the
# redirection MAY be altered on occasion, the client SHOULD continue to use the
# Request-URI for future requests. This response is only cacheable if indicated
# by a Cache-Control or Expires header field.
#
# The temporary URI SHOULD be given by the Location field in the response.
# Unless the request method was HEAD, the entity of the response SHOULD contain
# a short hypertext note with a hyperlink to the new URI(s) , since many
# pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note
# SHOULD contain the information necessary for a user to repeat the original
# request on the new URI.
#
# If the 307 status code is received in response to a request other than GET or
# HEAD, the user agent MUST NOT automatically redirect the request unless it can
# be confirmed by the user, since this might change the conditions under which
# the request was issued.
#
# __________ 10.4 Client Error 4xx
#
# The 4xx class of status code is intended for cases in which the client seems
# to have erred. Except when responding to a HEAD request, the server SHOULD
# include an entity containing an explanation of the error situation, and
# whether it is a temporary or permanent condition. These status codes are
# applicable to any request method. User agents SHOULD display any included
# entity to the user.
#
# If the client is sending data, a server implementation using TCP SHOULD be
# careful to ensure that the client acknowledges receipt of the packet(s)
# containing the response, before the server closes the input connection. If the
# client continues sending data to the server after the close, the server's TCP
# stack will send a reset packet to the client, which may erase the client's
# unacknowledged input buffers before they can be read and interpreted by the
# HTTP application.
#
# _____ 10.4.1 400 Bad Request
#
# The request could not be understood by the server due to malformed syntax. The
# client SHOULD NOT repeat the request without modifications.
#
# _____ 10.4.2 401 Unauthorized
#
# The request requires user authentication. The response MUST include a
# WWW-Authenticate header field (section 14.47) containing a challenge
# applicable to the requested resource. The client MAY repeat the request with a
# suitable Authorization header field (section 14.8). If the request already
# included Authorization credentials, then the 401 response indicates that
# authorization has been refused for those credentials. If the 401 response
# contains the same challenge as the prior response, and the user agent has
# already attempted authentication at least once, then the user SHOULD be
# presented the entity that was given in the response, since that entity might
# include relevant diagnostic information. HTTP access authentication is
# explained in "HTTP Authentication: Basic and Digest Access Authentication"
# [43].
#
# _____ 10.4.3 402 Payment Required
#
# This code is reserved for future use.
#
# _____ 10.4.4 403 Forbidden
#
# The server understood the request, but is refusing to fulfill it.
# Authorization will not help and the request SHOULD NOT be repeated. If the
# request method was not HEAD and the server wishes to make public why the
# request has not been fulfilled, it SHOULD describe the reason for the refusal
# in the entity. If the server does not wish to make this information available
# to the client, the status code 404 (Not Found) can be used instead.
#
# _____ 10.4.5 404 Not Found
#
# The server has not found anything matching the Request-URI. No indication is
# given of whether the condition is temporary or permanent. The 410 (Gone)
# status code SHOULD be used if the server knows, through some internally
# configurable mechanism, that an old resource is permanently unavailable and
# has no forwarding address. This status code is commonly used when the server
# does not wish to reveal exactly why the request has been refused, or when no
# other response is applicable.
#
# _____ 10.4.6 405 Method Not Allowed
#
# The method specified in the Request-Line is not allowed for the resource
# identified by the Request-URI. The response MUST include an Allow header
# containing a list of valid methods for the requested resource.
#
# _____ 10.4.7 406 Not Acceptable
#
# The resource identified by the request is only capable of generating response
# entities which have content characteristics not acceptable according to the
# accept headers sent in the request.
#
# Unless it was a HEAD request, the response SHOULD include an entity containing
# a list of available entity characteristics and location(s) from which the user
# or user agent can choose the one most appropriate. The entity format is
# specified by the media type given in the Content-Type header field. Depending
# upon the format and the capabilities of the user agent, selection of the most
# appropriate choice MAY be performed automatically. However, this specification
# does not define any standard for such automatic selection.
#
# Note: HTTP/1.1 servers are allowed to return responses which are not
# acceptable according to the accept headers sent in the request. In some
# cases, this may even be preferable to sending a 406 response. User
# agents are encouraged to inspect the headers of an incoming response to
# determine if it is acceptable.
#
# If the response could be unacceptable, a user agent SHOULD temporarily stop
# receipt of more data and query the user for a decision on further actions.
#
# _____ 10.4.8 407 Proxy Authentication Required
#
# This code is similar to 401 (Unauthorized), but indicates that the client must
# first authenticate itself with the proxy. The proxy MUST return a
# Proxy-Authenticate header field (section 14.33) containing a challenge
# applicable to the proxy for the requested resource. The client MAY repeat the
# request with a suitable Proxy-Authorization header field (section 14.34). HTTP
# access authentication is explained in "HTTP Authentication: Basic and Digest
# Access Authentication" [43].
#
# _____ 10.4.9 408 Request Timeout
#
# The client did not produce a request within the time that the server was
# prepared to wait. The client MAY repeat the request without modifications at
# any later time.
#
#
# _____ 10.4.10 409 Conflict
#
# The request could not be completed due to a conflict with the current state of
# the resource. This code is only allowed in situations where it is expected
# that the user might be able to resolve the conflict and resubmit the request.
# The response body SHOULD include enough
#
# information for the user to recognize the source of the conflict. Ideally, the
# response entity would include enough information for the user or user agent to
# fix the problem; however, that might not be possible and is not required.
#
# Conflicts are most likely to occur in response to a PUT request. For example,
# if versioning were being used and the entity being PUT included changes to a
# resource which conflict with those made by an earlier (third-party) request,
# the server might use the 409 response to indicate that it can't complete the
# request. In this case, the response entity would likely contain a list of the
# differences between the two versions in a format defined by the response
# Content-Type.
#
# _____ 10.4.11 410 Gone
#
# The requested resource is no longer available at the server and no forwarding
# address is known. This condition is expected to be considered permanent.
# Clients with link editing capabilities SHOULD delete references to the
# Request-URI after user approval. If the server does not know, or has no
# facility to determine, whether or not the condition is permanent, the status
# code 404 (Not Found) SHOULD be used instead. This response is cacheable unless
# indicated otherwise.
#
# The 410 response is primarily intended to assist the task of web maintenance
# by notifying the recipient that the resource is intentionally unavailable and
# that the server owners desire that remote links to that resource be removed.
# Such an event is common for limited-time, promotional services and for
# resources belonging to individuals no longer working at the server's site. It
# is not necessary to mark all permanently unavailable resources as "gone" or to
# keep the mark for any length of time -- that is left to the discretion of the
# server owner.
#
# _____ 10.4.12 411 Length Required
#
# The server refuses to accept the request without a defined Content- Length.
# The client MAY repeat the request if it adds a valid Content-Length header
# field containing the length of the message-body in the request message.
#
# _____ 10.4.13 412 Precondition Failed
#
# The precondition given in one or more of the request-header fields evaluated
# to false when it was tested on the server. This response code allows the
# client to place preconditions on the current resource metainformation (header
# field data) and thus prevent the requested method from being applied to a
# resource other than the one intended.
#
# _____ 10.4.14 413 Request Entity Too Large
#
# The server is refusing to process a request because the request entity is
# larger than the server is willing or able to process. The server MAY close the
# connection to prevent the client from continuing the request.
#
# If the condition is temporary, the server SHOULD include a Retry- After header
# field to indicate that it is temporary and after what time the client MAY try
# again.
#
# _____ 10.4.15 414 Request-URI Too Long
#
# The server is refusing to service the request because the Request-URI is
# longer than the server is willing to interpret. This rare condition is only
# likely to occur when a client has improperly converted a POST request to a GET
# request with long query information, when the client has descended into a URI
# "black hole" of redirection (e.g., a redirected URI prefix that points to a
# suffix of itself), or when the server is under attack by a client attempting
# to exploit security holes present in some servers using fixed-length buffers
# for reading or manipulating the Request-URI.
#
# _____ 10.4.16 415 Unsupported Media Type
#
# The server is refusing to service the request because the entity of the
# request is in a format not supported by the requested resource for the
# requested method.
#
# _____ 10.4.17 416 Requested Range Not Satisfiable
#
# A server SHOULD return a response with this status code if a request included
# a Range request-header field (section 14.35), and none of the range-specifier
# values in this field overlap the current extent of the selected resource, and
# the request did not include an If-Range request-header field. (For
# byte-ranges, this means that the first- byte-pos of all of the byte-range-spec
# values were greater than the current length of the selected resource.)
#
# When this status code is returned for a byte-range request, the response
# SHOULD include a Content-Range entity-header field specifying the current
# length of the selected resource (see section 14.16). This response MUST NOT
# use the multipart/byteranges content- type.
#
# _____ 10.4.18 417 Expectation Failed
#
# The expectation given in an Expect request-header field (see section 14.20)
# could not be met by this server, or, if the server is a proxy, the server has
# unambiguous evidence that the request could not be met by the next-hop server.
#
# __________ 10.5 Server Error 5xx
#
# Response status codes beginning with the digit "5" indicate cases in which the
# server is aware that it has erred or is incapable of performing the request.
# Except when responding to a HEAD request, the server SHOULD include an entity
# containing an explanation of the error situation, and whether it is a
# temporary or permanent condition. User agents SHOULD display any included
# entity to the user. These response codes are applicable to any request method.
#
# _____ 10.5.1 500 Internal Server Error
#
# The server encountered an unexpected condition which prevented it from
# fulfilling the request.
#
# _____ 10.5.2 501 Not Implemented
#
# The server does not support the functionality required to fulfill the request.
# This is the appropriate response when the server does not recognize the
# request method and is not capable of supporting it for any resource.
#
# _____ 10.5.3 502 Bad Gateway
#
# The server, while acting as a gateway or proxy, received an invalid response
# from the upstream server it accessed in attempting to fulfill the request.
#
# _____ 10.5.4 503 Service Unavailable
#
# The server is currently unable to handle the request due to a temporary
# overloading or maintenance of the server. The implication is that this is a
# temporary condition which will be alleviated after some delay. If known, the
# length of the delay MAY be indicated in a Retry-After header. If no
# Retry-After is given, the client SHOULD handle the response as it would for a
# 500 response.
#
# Note: The existence of the 503 status code does not imply that a server
# must use it when becoming overloaded. Some servers may wish to simply
# refuse the connection.
#
# _____ 10.5.5 504 Gateway Timeout
#
# The server, while acting as a gateway or proxy, did not receive a timely
# response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP)
# or some other auxiliary server (e.g. DNS) it needed to access in attempting to
# complete the request.
#
# Note: Note to implementors: some deployed proxies are known to return
# 400 or 500 when DNS lookups time out.
#
# _____ 10.5.6 505 HTTP Version Not Supported
#
# The server does not support, or refuses to support, the HTTP protocol version
# that was used in the request message. The server is indicating that it is
# unable or unwilling to complete the request using the same major version as
# the client, as described in section 3.1, other than with this error message.
# The response SHOULD contain an entity describing why that version is not
# supported and what other protocols are supported by that server.
@Knah-Tsaeb

This comment has been minimized.

Copy link

@Knah-Tsaeb Knah-Tsaeb commented Mar 19, 2013

Thanks for share this script.

@pelligrag

This comment has been minimized.

Copy link

@pelligrag pelligrag commented Mar 15, 2017

Thank you, very useful!

@ghost

This comment has been minimized.

Copy link

@ghost ghost commented Oct 25, 2020

Nice function, thanks!

@rojenzaman

This comment has been minimized.

Copy link

@rojenzaman rojenzaman commented Jun 9, 2021

Just thanks! The case statement saved my time for my script.

@rojenzaman

This comment has been minimized.

Copy link

@rojenzaman rojenzaman commented Jun 9, 2021

I've added more status codes and simplified the code, also the script returns true or false.

#!/bin/bash
URL=${1}

if [ "$#" -lt 1 ]; then
    echo "Usage: ./`basename $0` URL"
    exit 1
fi

function unknown_status() {
    if [ "${code::1}" == "4" ]; then
        echo "Unknown Client Error"
        exit 1
    fi

    if [ "${code::1}" == "5" ]; then
        echo "Unknown Server Error"
        exit 1
    fi

    echo "${code} !! `basename $0`: status not defined."
    exit 0
}

code=$(curl --write-out %{http_code} --silent --no-keepalive --output /dev/null $URL)

case $code in
     000) echo "${code} Not responding" ; exit 1 ;;
     100) echo "${code} Informational: Continue" ;;
     101) echo "${code} Informational: Switching Protocols" ;;
     102) echo "${code} Informational: Processing" ;;
     103) echo "${code} Informational: Early Hints" ;;
     200) echo "${code} Successful: OK" ;;
     201) echo "${code} Successful: Created" ;;
     202) echo "${code} Successful: Accepted" ;;
     203) echo "${code} Successful: Non-Authoritative Information" ;;
     204) echo "${code} Successful: No Content" ;;
     205) echo "${code} Successful: Reset Content" ;;
     206) echo "${code} Successful: Partial Content" ;;
     207) echo "${code} Successful: Multi-Status" ;;
     208) echo "${code} Successful: Already Reported" ;;
     218) echo "${code} Apache Web Server: This Is Fine" ;;
     226) echo "${code} Successful: IM Used" ;;
     300) echo "${code} Redirection: Multiple Choices" ;;
     301) echo "${code} Redirection: Moved Permanently" ;;
     302) echo "${code} Redirection: Found residing temporarily under different URI" ;;
     303) echo "${code} Redirection: See Other" ;;
     304) echo "${code} Redirection: Not Modified" ;;
     305) echo "${code} Redirection: Use Proxy" ;;
     306) echo "${code} Redirection: status not defined" ;;
     307) echo "${code} Redirection: Temporary Redirect" ;;
     308) echo "${code} Redirection: Permanent Redirect" ;;
     400) echo "${code} Client Error: Bad Request" ; exit 1 ;;
     401) echo "${code} Client Error: Unauthorized" ; exit 1 ;;
     402) echo "${code} Client Error: Payment Required" ; exit 1 ;;
     403) echo "${code} Client Error: Forbidden" ; exit 1 ;;
     404) echo "${code} Client Error: Not Found" ; exit 1 ;;
     405) echo "${code} Client Error: Method Not Allowed" ; exit 1 ;;
     406) echo "${code} Client Error: Not Acceptable" ; exit 1 ;;
     407) echo "${code} Client Error: Proxy Authentication Required" ; exit 1 ;;
     408) echo "${code} Client Error: Request Timeout" ; exit 1 ;;
     409) echo "${code} Client Error: Conflict" ; exit 1 ;;
     410) echo "${code} Client Error: Gone" ; exit 1 ;;
     411) echo "${code} Client Error: Length Required" ; exit 1 ;;
     412) echo "${code} Client Error: Precondition Failed" ; exit 1 ;;
     413) echo "${code} Client Error: Request Entity Too Large" ; exit 1 ;;
     414) echo "${code} Client Error: Request-URI Too Long" ; exit 1 ;;
     415) echo "${code} Client Error: Unsupported Media Type" ; exit 1 ;;
     416) echo "${code} Client Error: Requested Range Not Satisfiable" ; exit 1 ;;
     417) echo "${code} Client Error: Expectation Failed" ; exit 1 ;;
     418) echo "${code} Client Error: I'm a teapot" ; exit 1 ;;
     419) echo "${code} Laravel Framework: Page Expired" ; exit 1 ;;
     420) echo "${code} Spring Framework: Method Failure" ; exit 1 ;;
     421) echo "${code} Client Error: Misdirected Request" ; exit 1 ;;
     422) echo "${code} Client Error: Unprocessable Entity" ; exit 1 ;;
     423) echo "${code} Client Error: Locked" ; exit 1 ;;
     424) echo "${code} Client Error: Failed Dependency" ; exit 1 ;;
     425) echo "${code} Client Error: Too Early" ; exit 1 ;;
     426) echo "${code} Client Error: Upgrade Required" ; exit 1 ;;
     428) echo "${code} Client Error: Precondition Required" ; exit 1 ;;
     429) echo "${code} Client Error: Too Many Requests" ; exit 1 ;;
     430) echo "${code} Shopify: Request Header Fields Too Large" ; exit 1 ;;
     431) echo "${code} Client Error: Request Header Fields Too Large" ; exit 1 ;;
     440) echo "${code} Internet Information Services Error: Login Time-out" ; exit 1 ;;
     444) echo "${code} NGINX Error: No Response" ; exit 1 ;;
     449) echo "${code} Internet Information Services Error: Retry With" ; exit 1 ;;
     450) echo "${code} Microsoft: Blocked by Windows Parental Controls" ; exit 1 ;;
     451) echo "${code} Client Error: Unavailable For Legal Reasons" ;;
     460) echo "${code} AWS Elastic Load Balancer Error: Client closed the connection with the load balancer before the idle timeout period elapsed." ; exit 1 ;;
     463) echo "${code} AWS Elastic Load Balancer Error: The load balancer received an X-Forwarded-For request header with more than 30 IP addresses." ; exit 1 ;;
     494) echo "${code} NGINX Error: Request Header Too Large" ; exit 1 ;;
     495) echo "${code} NGINX Error: SSL Certificate Error" ; exit 1 ;;
     496) echo "${code} NGINX Error: SSL Certificate Required" ; exit 1 ;;
     497) echo "${code} NGINX Error: HTTP Request Sent to HTTPS Port" ; exit 1 ;;
     498) echo "${code} Esri: Invalid Token" ; exit 1 ;;
     499) echo "${code} NGINX Error: Client Closed Request" ; exit 1 ;;
     500) echo "${code} Server Error: Internal Server Error" ; exit 1 ;;
     501) echo "${code} Server Error: Not Implemented" ; exit 1 ;;
     502) echo "${code} Server Error: Bad Gateway" ; exit 1 ;;
     503) echo "${code} Server Error: Service Unavailable" ; exit 1 ;;
     504) echo "${code} Server Error: Gateway Timeout" ; exit 1 ;;
     505) echo "${code} Server Error: HTTP Version Not Supported" ; exit 1 ;;
     506) echo "${code} Server Error: Variant Also Negotiates" ; exit 1 ;;
     507) echo "${code} Server Error: Insufficient Storage" ; exit 1 ;;
     508) echo "${code} Server Error: Loop Detected" ; exit 1 ;;
     509) echo "${code} Apache Web Server/cPanel: Bandwidth Limit Exceeded" ; exit 1 ;;
     510) echo "${code} Server Error: Not Extended" ; exit 1 ;;
     511) echo "${code} Server Error: Network Authentication Required" ; exit 1 ;;
     520) echo "${code} Cloudflare Error: Web Server Returned an Unknown Error" ; exit 1 ;;
     521) echo "${code} Cloudflare Error: Web Server Is Down" ; exit 1 ;;
     522) echo "${code} Cloudflare Error: Connection Timed Out" ; exit 1 ;;
     523) echo "${code} Cloudflare Error: Origin Is Unreachable" ; exit 1 ;;
     524) echo "${code} Cloudflare Error: A Timeout Occurred" ; exit 1 ;;
     525) echo "${code} Cloudflare Error: SSL Handshake Failed" ; exit 1 ;;
     526) echo "${code} Cloudflare Error: Invalid SSL Certificate" ; exit 1 ;;
     527) echo "${code} Cloudflare Error: Railgun Error" ; exit 1 ;;
     529) echo "${code} Qualys: Site is overloaded" ; exit 1 ;;
     530) echo "${code} Cloudflare Error: 1XXX Error" ; exit 1 ;;
     561) echo "${code} AWS Elastic Load Balancer Error: Unauthorized" ; exit 1 ;;
     598) echo "${code} Server Error: Network read timeout error" ; exit 1 ;;
     *) unknown_status ;;
esac

exit 0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment