httpstatus : bash script to get HTTP response code with optional status message (includes verbose definitions in comment)

httpstatus

#!/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. 

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

script will stuck for long if domain/url is not responding.... i have added timeout field and parameter 'k' for taking care of certificate expired error.
Code is available here - https://github.com/kansal15/http-codes