5 Solicitao

Uma mensagem de solicitao de um cliente para um servidor inclui, na primeira linha da mensagem, o mtodo a ser aplicado ao recurso, o identificador do recurso e a verso do protocolo em uso.

        Request       = Request-Line              ; Section 5.1
                        *(( general-header        ; Section 4.5
                         | request-header         ; Section 5.3
                         | entity-header ) CRLF)  ; Section 7.1
                        CRLF
                        [ message-body ]          ; Section 4.3

5.1 Linha de solicitao

A linha de solicitao comea com um token de mtodo, seguido pela solicitao-URI e a verso do protocolo e terminando com CRLF. Os elementos so separados por caracteres SP. Nenhum CR ou LF  permitido, exceto na seqncia final do CRLF.

	Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

5.1.1 Metodo

O token Method indica o mtodo a ser executado no recurso identificado pelo Request-URI. O mtodo  sensvel a maisculas e minsculas.

       Method         = "OPTIONS"                ; Section 9.2
                      | "GET"                    ; Section 9.3
                      | "HEAD"                   ; Section 9.4
                      | "POST"                   ; Section 9.5
                      | "PUT"                    ; Section 9.6
                      | "DELETE"                 ; Section 9.7
                      | "TRACE"                  ; Section 9.8
                      | "CONNECT"                ; Section 9.9
                      | extension-method
       extension-method = token

A lista de mtodos permitidos por um recurso pode ser especificada em um campo de cabealho permitido (seo 14.7). O cdigo de retorno da resposta sempre notifica o cliente se um mtodo  atualmente permitido em um recurso, uma vez que o conjunto de mtodos permitidos pode ser alterado dinamicamente. Um servidor de origem DEVE retornar o cdigo de status 405 (Mtodo no permitido) se o mtodo for conhecido pelo servidor de origem, mas no permitido pelo recurso solicitado, e 501 (No implementado) se o mtodo no for reconhecido ou no for implementado pelo servidor de origem. Os mtodos GET e HEAD DEVEM ser suportados por todos os servidores de propsito geral. Todos os outros mtodos so opcionais; no entanto, se os mtodos acima forem implementados, eles DEVEM ser implementados com a mesma semntica especificada na seo 9.

5.1.2 Request-URI

O Request-URI  um Identificador Uniforme de Recursos (seo 3.2) e identifica o recurso sobre o qual aplicar o pedido.

	Request-URI    = "*" | absoluteURI | abs_path | authority

As quatro opes para solicitao-URI dependem da natureza da solicitao. O asterisco "*" significa que a solicitao no se aplica a um recurso especfico, mas ao prprio servidor, e  permitida somente quando o mtodo usado no se aplica necessariamente a um recurso. Um exemplo seria

	OPTIONS * HTTP/1.1

O formulrio absoluteURI  NECESSRIO quando o pedido est sendo feito para um proxy. O proxy  solicitado para encaminhar a solicitao ou atend-la a partir de um cache vlido e retornar a resposta. Observe que o proxy pode encaminhar o pedido para outro proxy ou diretamente para o servidor especificado pelo absoluteURI. Para evitar loops de solicitao, um proxy DEVE poder reconhecer todos os nomes de servidor, incluindo aliases, variaes locais e o endereo IP numrico. Um exemplo de linha de solicitao seria:

	GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

Para permitir a transio para absoluteURIs em todas as solicitaes em futuras verses do HTTP, todos os servidores HTTP / 1.1 DEVEM aceitar o formulrio absoluteURI em solicitaes, mesmo que os clientes HTTP / 1.1 os gerem apenas em solicitaes para proxies.

O formulrio de autoridade  usado apenas pelo mtodo CONNECT (seo 9.9).

A forma mais comum de URI de solicitao  aquela usada para identificar um recurso em um servidor ou gateway de origem. Nesse caso, o caminho absoluto da URI DEVE ser transmitido (consulte a seo 3.2.1, abs_path) como a Solicitao-URI, e a localizao da rede da URI (autoridade) DEVE ser transmitida em um campo de cabealho de host. Por exemplo, um cliente que deseja recuperar o recurso acima diretamente do servidor de origem criaria uma conexo TCP para a porta 80 do host "www.w3.org" e enviaria as linhas:

	GET /pub/WWW/TheProject.html HTTP/1.1
       	Host: www.w3.org

seguido pelo restante do Pedido. Observe que o caminho absoluto no pode estar vazio; se nenhum estiver presente no URI original, ele DEVE ser fornecido como "/" (a raiz do servidor).

O Request-URI  transmitido no formato especificado na seo 3.2.1. Se o Request-URI for codificado usando a codificao "% HEX HEX" [42], o servidor de origem DEVE decodificar o Request-URI para poder interpretar corretamente o pedido. Os servidores DEVEM responder a URIs de solicitao invlidos com um cdigo de status apropriado.

Um proxy transparente NO DEVE reescrever a parte "abs_path" do Request-URI recebido ao encaminh-lo para o prximo servidor de entrada, exceto como indicado acima para substituir um abs_path nulo por "/".

 Nota: A regra "no reescrever" impede que o proxy altere o significado da solicitao quando o servidor de origem estiver usando indevidamente um caractere URI no reservado para uma finalidade reservada. Os implementadores devem estar cientes de que alguns proxies pr-HTTP / 1.1 so conhecidos por reescrever o Request-URI.

5.2 O recurso identificado por uma solicitao.

O recurso exato identificado por uma solicitao da Internet  determinado examinando-se o campo Request-URI e o cabealho do host.

Um servidor de origem que no permite que os recursos sejam diferentes pelo host solicitado pode ignorar o valor do campo de cabealho do host ao determinar o recurso identificado por uma solicitao HTTP / 1.1. (Mas veja a seo 19.6.1.1 para outros requisitos sobre suporte ao Host em HTTP / 1.1.)

Um servidor de origem que diferencia os recursos com base no host solicitado (s vezes chamado de hosts virtuais ou nomes de host de cortesia) DEVE usar as seguintes regras para determinar o recurso solicitado em uma solicitao HTTP / 1.1:

	1. Se Request-URI for um absoluteURI, o host faz parte do Request-URI. Qualquer valor de campo de cabealho de host na solicitao deve ser ignorado.

 2. Se a Solicitao-URI no for um absoluteURI e a solicitao incluir um campo de cabealho do Host, o host ser determinado pelo valor do campo de cabealho do Host.

 3. Se o host, conforme determinado pela regra 1 ou 2, no for um host vlido no servidor, a resposta DEVE ser uma mensagem de erro 400 (Solicitao incorreta).

Destinatrios de uma solicitao HTTP / 1.0 sem um campo de cabealho de host PODEM tentar usar heurstica (por exemplo, exame do caminho de URI para algo exclusivo de um determinado host) para determinar qual recurso exato est sendo solicitado.

5.3 Campos de cabealho de solicitao

Os campos de cabealho de solicitao permitem que o cliente passe informaes adicionais sobre a solicitao e sobre o prprio cliente para o servidor. Esses campos atuam como modificadores de solicitao, com semntica equivalente aos parmetros em uma chamada de mtodo de linguagem de programao.

       request-header = Accept                   ; Section 14.1
                      | Accept-Charset           ; Section 14.2
                      | Accept-Encoding          ; Section 14.3
                      | Accept-Language          ; Section 14.4
                      | Authorization            ; Section 14.8
                      | Expect                   ; Section 14.20
                      | From                     ; Section 14.22
                      | Host                     ; Section 14.23
                      | If-Match                 ; Section 14.24
		      | If-Modified-Since        ; Section 14.25
                      | If-None-Match            ; Section 14.26
                      | If-Range                 ; Section 14.27
                      | If-Unmodified-Since      ; Section 14.28
                      | Max-Forwards             ; Section 14.31
                      | Proxy-Authorization      ; Section 14.34
                      | Range                    ; Section 14.35
                      | Referer                  ; Section 14.36
                      | TE                       ; Section 14.39
                      | User-Agent               ; Section 14.43

Os nomes dos campos de cabealho de solicitao podem ser estendidos de forma confivel somente em combinao com uma alterao na verso do protocolo. No entanto, campos de cabealho novos ou experimentais PODEM receber a semntica dos campos de cabealho de solicitao se todas as partes na comunicao reconhec-los como campos de cabealho de solicitao. Campos de cabealho no reconhecidos so tratados como campos de cabealho de entidade.

6 Resposta

Depois de receber e interpretar uma mensagem de solicitao, um servidor responde com uma mensagem de resposta HTTP.

       Response      = Status-Line               ; Section 6.1
                       *(( general-header        ; Section 4.5
                        | response-header        ; Section 6.2
                        | entity-header ) CRLF)  ; Section 7.1
                       CRLF
                       [ message-body ]          ; Section 7.2

6.1 Linha de Status

A primeira linha de uma mensagem de Resposta  a Linha de Status, consistindo na verso do protocolo seguida por um cdigo de status numrico e sua frase textual associada, com cada elemento separado por caracteres SP. Nenhum CR ou LF  permitido, exceto na seqncia final do CRLF.

	Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

6.1.1 Cdigo de Status e Frase da Razo

O elemento Cdigo de Status  um cdigo de resultado inteiro de 3 dgitos da tentativa de entender e satisfazer a solicitao. Esses cdigos so totalmente definidos na seo 10. A Frase-Razo tem a inteno de fornecer uma breve descrio textual do Cdigo de Status. O Cdigo de Status destina-se ao uso de autmatos e a Frase de Razo  destinada ao usurio humano. O cliente no  obrigado a examinar ou exibir a Frase-Razo.

The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit:

      - 1xx: Informational - Request received, continuing process

      - 2xx: Success - The action was successfully received,
        understood, and accepted

      - 3xx: Redirection - Further action must be taken in order to
        complete the request

      - 4xx: Client Error - The request contains bad syntax or cannot
        be fulfilled

      - 5xx: Server Error - The server failed to fulfill an apparently
        valid request

Os valores individuais dos cdigos de status numricos definidos para HTTP / 1.1 e um conjunto de exemplo de Frase de Razo correspondentes so apresentados abaixo. A razo pela qual as frases listadas aqui so apenas recomendaes - elas podem ser substitudas por equivalentes locais sem afetar o protocolo.

	Status-Code    =
            "100"  ; Section 10.1.1: Continue
          | "101"  ; Section 10.1.2: Switching Protocols
          | "200"  ; Section 10.2.1: OK
          | "201"  ; Section 10.2.2: Created
          | "202"  ; Section 10.2.3: Accepted
          | "203"  ; Section 10.2.4: Non-Authoritative Information
          | "204"  ; Section 10.2.5: No Content
          | "205"  ; Section 10.2.6: Reset Content
          | "206"  ; Section 10.2.7: Partial Content
          | "300"  ; Section 10.3.1: Multiple Choices
          | "301"  ; Section 10.3.2: Moved Permanently
          | "302"  ; Section 10.3.3: Found
          | "303"  ; Section 10.3.4: See Other
          | "304"  ; Section 10.3.5: Not Modified
          | "305"  ; Section 10.3.6: Use Proxy
          | "307"  ; Section 10.3.8: Temporary Redirect
          | "400"  ; Section 10.4.1: Bad Request
          | "401"  ; Section 10.4.2: Unauthorized
          | "402"  ; Section 10.4.3: Payment Required
          | "403"  ; Section 10.4.4: Forbidden
          | "404"  ; Section 10.4.5: Not Found
          | "405"  ; Section 10.4.6: Method Not Allowed
          | "406"  ; Section 10.4.7: Not Acceptable
          | "407"  ; Section 10.4.8: Proxy Authentication Required
          | "408"  ; Section 10.4.9: Request Time-out
          | "409"  ; Section 10.4.10: Conflict
          | "410"  ; Section 10.4.11: Gone
          | "411"  ; Section 10.4.12: Length Required
          | "412"  ; Section 10.4.13: Precondition Failed
          | "413"  ; Section 10.4.14: Request Entity Too Large
          | "414"  ; Section 10.4.15: Request-URI Too Large
          | "415"  ; Section 10.4.16: Unsupported Media Type
          | "416"  ; Section 10.4.17: Requested range not satisfiable
          | "417"  ; Section 10.4.18: Expectation Failed
          | "500"  ; Section 10.5.1: Internal Server Error
          | "501"  ; Section 10.5.2: Not Implemented
          | "502"  ; Section 10.5.3: Bad Gateway
          | "503"  ; Section 10.5.4: Service Unavailable
          | "504"  ; Section 10.5.5: Gateway Time-out
          | "505"  ; Section 10.5.6: HTTP Version not supported
          | extension-code

      extension-code = 3DIGIT
      Reason-Phrase  = *<TEXT, excluding CR, LF>

Cdigos de status HTTP so extensveis. Aplicativos HTTP no so necessrios para entender o significado de todos os cdigos de status registrados, embora tal entendimento seja obviamente desejvel. No entanto, os aplicativos devem compreender a classe de qualquer cdigo de status, conforme indicado pelo primeiro dgito, e tratar qualquer resposta no reconhecida como sendo equivalente ao cdigo de status x00 dessa classe, com a exceo de que uma resposta no reconhecida NO DEVE ser armazenada em cache. Por exemplo, se um cdigo de status no reconhecido de 431 for recebido pelo cliente, ele poder assumir com segurana que havia algo errado com sua solicitao e tratar a resposta como se tivesse recebido um cdigo de status 400. Nesses casos, os agentes do usurio devem apresentar ao usurio a entidade retornada com a resposta, uma vez que essa entidade provavelmente incluir informaes legveis que explicaro o status incomum.

6.2 Campos do Cabealho de Resposta

Os campos de cabealho de resposta permitem que o servidor passe informaes adicionais sobre a resposta que no pode ser colocada na Linha de Status. Esses campos de cabealho fornecem informaes sobre o servidor e sobre o acesso adicional ao recurso identificado pelo Request-URI.

       response-header = Accept-Ranges           ; Section 14.5
                       | Age                     ; Section 14.6
                       | ETag                    ; Section 14.19
                       | Location                ; Section 14.30
                       | Proxy-Authenticate      ; Section 14.33
                       | Retry-After             ; Section 14.37
                       | Server                  ; Section 14.38
                       | Vary                    ; Section 14.44
                       | WWW-Authenticate        ; Section 14.47

Os nomes dos campos de cabealho de resposta podem ser estendidos de forma confivel somente em combinao com uma alterao na verso do protocolo. No entanto, campos de cabealho novos ou experimentais PODEM receber a semntica dos campos de cabealho de resposta se todas as partes na comunicao os reconhecerem como campos de cabealho de resposta. Campos de cabealho no reconhecidos so tratados como campos de cabealho de entidade.
