Skip to content

Instantly share code, notes, and snippets.

@rsvp

rsvp/httpstatus

Created August 25, 2011 18:00
Download ZIP

Revisions

  1. Adriano revised this gist Aug 26, 2011. 1 changed file with 18 additions and 8 deletions.
    26 changes: 18 additions & 8 deletions httpstatus
    View file
    Original file line number Diff line number Diff line change
    @@ -3,11 +3,13 @@
    #
    # _______________| httpstatus : get HTTP status code
    #
    # Usage: httpstatus URL [timeout] [-c or -s]
    # ^status with code (default)
    # ^code (numeric only)
    # ^in secs (default: 3)
    # ^URL without "http://" prefix works fine.
    # 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
    #
    @@ -20,7 +22,7 @@
    # 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 work; e.g. bit.ly).
    # (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/
    @@ -47,10 +49,18 @@ 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 --connect-timeout $timeout \
    --no-keepalive --output /dev/null $url)`
    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:
  2. Adriano revised this gist Aug 25, 2011. 1 changed file with 8 additions and 7 deletions.
    15 changes: 8 additions & 7 deletions httpstatus
    View file
    Original file line number Diff line number Diff line change
    @@ -15,7 +15,8 @@
    # 301 Redirection: Moved Permanently

    # CHANGE LOG
    # 2011-08-25 Add timeout and status info. Restrict query to one URL.
    # 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
    @@ -35,6 +36,7 @@

    # _____ Prelims
    set -u
    # ^ unbound (i.e. unassigned) variables shall be errors.
    set -e
    # ^ error checking :: Highly Recommended (caveat: you can't check $? later).
    #
    @@ -109,9 +111,12 @@ case $flag in
    esac


    exit 0
    # _______________ EOS :: END of Script ::::::::::::::::::::::::::::::::::::::::

    # _______________ 10 STATUS CODE DEFINITIONS
    # part of Hypertext Transfer Protocol -- HTTP/1.1

    # _______________ 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
    @@ -711,7 +716,3 @@ esac
    # The response SHOULD contain an entity describing why that version is not
    # supported and what other protocols are supported by that server.



    exit 0
    # _______________ EOS :: END of Script ::::::::::::::::::::::::::::::::::::::::
  3. Adriano revised this gist Aug 25, 2011. 1 changed file with 2 additions and 1 deletion.
    3 changes: 2 additions & 1 deletion httpstatus
    View file
    Original file line number Diff line number Diff line change
    @@ -4,7 +4,8 @@
    # _______________| httpstatus : get HTTP status code
    #
    # Usage: httpstatus URL [timeout] [-c or -s]
    # ^status with code (default) # ^code (numeric only)
    # ^status with code (default)
    # ^code (numeric only)
    # ^in secs (default: 3)
    # ^URL without "http://" prefix works fine.
    #
  4. Adriano created this gist Aug 25, 2011.
    716 changes: 716 additions & 0 deletions httpstatus
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,716 @@
    #!/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] [-c or -s]
    # ^status with code (default) # ^code (numeric only)
    # ^in secs (default: 3)
    # ^URL without "http://" prefix works fine.
    #
    # Dependencies: curl
    #
    # Example: $ httpstatus bit.ly
    # 301 Redirection: Moved Permanently

    # CHANGE LOG
    # 2011-08-25 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 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
    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'}


    # __________ get the CODE which is numeric:
    code=`echo $(curl --write-out %{http_code} --silent --connect-timeout $timeout \
    --no-keepalive --output /dev/null $url)`


    # __________ 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



    # _______________ 10 STATUS CODE DEFINITIONS
    # part of 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.



    exit 0
    # _______________ EOS :: END of Script ::::::::::::::::::::::::::::::::::::::::