IMPORTANT: Per accedir als fitxer de subversion: http://acacha.org/svn (sense password). Poc a poc s'aniran migrant els enllaços. Encara però funciona el subversion de la farga però no se sap fins quan... (usuari: prova i la paraula de pas 123456)

El protocol Hypertext Transfer Protocol és un protocol de nivell d'aplicació per a sistemes d'informació distribuits, col·laboratius i amb hypermedia. És un protocol sense estat

HTTP per a desenvolupadors

Conceptes

Llista amb els seus enllaços

URL REDIRECTION

Consulteu HTML#Redireccions.


Missatges HTTP

HTTP REQUEST

HTTP RESPONSE

HTTP Header Fields

HTTP Header Fields

Recursos:

REQUEST

httpie

Es poden indicar capçaleres de request amb:

$ http example.org  User-Agent:Bacon/1.0  'Cookie:valued-visitor=yes;foo=bar'  X-Foo:Bar  Referer:http://httpie.org/

HOST

Conté el nom de domini del servidor i el port demanat durant la petició. Sinó s'indica el port de suposa el port per defecte. Exemples:

Host: en.wikipedia.org:8080
Host: en.wikipedia.org

IMPORTANT: Aquest camp és obligatori des de la versió HTTP1.1

Cal tenir en compte que tot i que pot semblar redundant per que la informació ja està a la URL això no és cert. A les peticions HTTP no va la URL completa sinó només la URI és a dir precisament el que va després del nom de servidor i port.

Els servidors utilitzen aquesta informació per exemple per implementar Virtual Hosting (mateixa IP física, múltiples pàgines/dominis web)


User-Agent

Indica el tipus del navegador. Es pot utilitzar per a fer estadístiques de visites però millor no utilitzar (mala pràctica i evidentment no segura) per a servir diferent contingut depenen del navegador

FROM

Conté un email.No és un camp obligatori i s'utilitza per posar una adreça de contacte del qui realitza les peticions. Els navegadors no ho posen però està pensat per aplicacions robot tipus spiders poder posar una adreça de contacte per posar-se en contacte amb l'autor de l'aranya.

Resources

Authorization

The Authorization request-header field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested. The general syntax is:

Authorization : credentials

The HTTP/1.0 specification defines the BASIC authorization scheme, where the authorization parameter is the string of username:password encoded in base 64. Following is an example:

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

The value decodes into is guest:guest123 where guest is user ID and guest123 is the password.

Cookie

Vegeu Cookies

The Cookie request-header field value contains a name/value pair of information stored for that URL. Following is the general syntax:

Cookie: name=value

Multiple cookies can be specified separated by semicolons as follows:

Cookie: name1=value1;name2=value2;name3=value3

REFERER

Exemple manual:

Pàgina origen:

<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<title>Document</title>
</head>
<body>
	<a href="headers.php">Link to header1.php</a>
</body>
</html>

Fitxer headers.php:

<?php

var_dump(getallheaders());

El resultat després de seguir el link és:

/home/sergi/HTTP/prova/header1.php:3:
array (size=9)
  ...
  'User-Agent' => string 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36' (length=105)
  'Referer' => string 'http://127.0.0.1:8000/paginaorigen.html' (length=39)

Resources:

RESPONSE

WWW-Authenticate

   header('WWW-Authenticate: Basic realm="My Realm"');
   header('HTTP/1.0 401 Unauthorized');

PHP

Dos tipus, el primer per indicar el codi de resposta:

header("HTTP/1.1 404 Not Found");

O per a un header en si mateix:

header("Location: http://www.example.com/"); /* Redirect browser */


Codis de resposta. HTTP Response Codes

HTTP Response Codes

Request methods

També coneguts com a HTTP verbs

Recursos

POST

Vegeu també:

GET

GET vs POST

Vegeu les diferències a:

http://www.w3schools.com/tags/ref_httpmethods.asp

Formularis HTML

Vegeu Formularis HTML

PUT

PATCH

DELETE

HTTP Status Code

HTTP Status Code

HTTP status codes in the response body tells client application what action should be taken with the response. For an example if the response code 200, it means on the server side the request is processed successfully and you can expect updated data in the response. As well if the status code is 401, the request is not authorized. An example cause for 401 could be api key is invalid.

It is not necessary to support all HTTP status codes, but supporting at least the following codes should be good enough. Check out list of http codes from restapitutorial.com and Wikipedia

200	OK
201	Created
304	Not Modified
400	Bad Request
401	Unauthorized
403	Forbidden
404	Not Found
422	Unprocessable Entity
500	Internal Server Error

Llista completa:

http://www.rfc-editor.org/rfc/rfc2616.txt
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

URL Structure

In REST design the URL endpoints should be well formed and should be easily understandable. Every URL for a resource should be uniquely identified. If your API needs an API key to access, the api key should be kept in HTTP headers instead of including it in URL.

For an example:

GET http://abc.com/v1/tasks/11 – Will give the details of a task whose id is 11
POST http://abc.com/v1/tasks – Will create a new task

API Versioning

There is a huge discussion on API versioning whether to maintain api version in the URL or in the HTTP request headers. Even though it is recommended that version should be included in the request headers, I feel comfortable to maintain it in the URL itself as it is very convenient on the client side to migrate from one version to another.

Example:

http://abc.com/v1/tasks
http://abc.com/v2/tasks

Content Type

The Content Type in HTTP headers specifies the kind of the data should be transferred between server and client. Depending upon the data your API supporting you need to set the content type.

For an example, JSON Mime type should be Content-Type: application/json, for XML Content-Type: application/xml. You can find list of supported MIME Types here

Recursos:

HTTP Authentication

rfc2617 : http://tools.ietf.org/html/rfc2617

httpie

Fàcil:

$ http -a username:password example.org

Request header Authorization

Als headers/capçaleres d'una petició HTTP (HTTP REQUEST) hi ha una capçalera que s'utilitza per enviar l'autorització anomenada

Request header Authorization

Exemple:

Authorization: bf45c093e542f057caee68c47787e7d6

És recomanable protegir aquest informació amb SSL i/o tècniques com nonce o digests.

Format:

Authorization  = "Authorization" ":" credentials

Per exemple amb l'ús de API Tokens

Authorization =  Bearer njd9wng4d0ycwnn3g4d1jm30yig4d27iom5lg4d3

El format de l'autenticació bàsica HTTP (HTTP Basic Authentication) és base64:

$header = "Authorization: Basic " . base64_encode($username . ':' . $password);

ho podeu veure amb httpie

$ http -v http://username:password@localhost:8000/fragments.php?arg=value#anchor
GET /fragments.php?arg=value HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
Connection: keep-alive
Host: localhost:8000
User-Agent: HTTPie/0.9.2

A user agent that wishes to authenticate itself with a server usually, but not necessarily, after receiving a 401 response--does so by including an Authorization request-header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

HTTP access authentication is described in "HTTP Authentication: Basic and Digest Access Authentication" [43]. If a request is authenticated and a realm specified, the same credentials SHOULD be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks).

Recursos:

PHP

<?php
if (!isset($_SERVER['PHP_AUTH_USER'])) {
    header('WWW-Authenticate: Basic realm="My Realm"');
    header('HTTP/1.0 401 Unauthorized');
    echo 'Texte utilisé si le visiteur utilise le bouton d\'annulation';
    exit;
} else {
    echo "<p>Bonjour, {$_SERVER['PHP_AUTH_USER']}.</p>";
    echo "<p>Votre mot de passe est {$_SERVER['PHP_AUTH_PW']}.</p>";
}
?>

HTTP Basic

HTTP Basic

HTTP Digest

HTTP Digest aka Digest_access_authentication

Digest access authentication is one of the agreed-upon methods a web server can use to negotiate credentials, such as username or password, with a user's web browser. This can be used to confirm the identity of a user before sending sensitive information, such as online banking transaction history. It applies a hash function to a password before sending it over the network, which is safer than basic access authentication, which sends plaintext.

Tècnicament l'autenticació digest utilitza:

Gràfica:

S'ha produït un error en crear la miniatura: /bin/bash: /usr/bin/rsvg-convert/rsvg: Not a directory
http://upload.wikimedia.org/wikipedia/commons/4/4f/Nonce-cnonce-uml.svg

Vegeu també:

Recursos:

API Key

Vegeu API Key

Implementació a Apache

Apache. Consulteu Apache#Autenticaci.C3.B3_Digest.htpasswd

HTTPIE

Vegeu httpie

Curl com a REST Client

Vegeu curl o Curl_com_a_rest_client

Cache

Etag

NOTA: S'utilitzen sovint com a una especie de fingerprint o hash d'un recurs HTTP. Permet saber si el recurs ha canviat (té un eTag diferent al anterior) o no per tal de saber si podem o no fer cache

The ETag or entity tag is part of HTTP, the protocol for the World Wide Web. It is one of several mechanisms that HTTP provides for web cache validation, and which allows a client to make conditional requests. This allows caches to be more efficient, and saves bandwidth, as a web server does not need to send a full response if the content has not changed. ETags can also be used for optimistic concurrency control,[1] as a way to help prevent simultaneous updates of a resource from overwriting each other.

An ETag is an opaque identifier assigned by a web server to a specific version of a resource found at a URL. If the resource content at that URL ever changes, a new and different ETag is assigned. Used in this manner ETags are similar to fingerprints, and they can be quickly compared to determine whether two versions of a resource are the same. Comparing ETags only makes sense with respect to one URL—ETags for resources obtained from different URLs may or may not be equal, so no meaning can be inferred from their comparison.

PHP i HTTP

PHP i HTTP

Javascript i HTTP

Vegeu Javascript i HTTP

Session

Vegeu HTTP Session

Cookies

Vegeu HTTP Cookies

Content-negotation

Content-negotation a HTTP és el mecanisme que s'utilitza per tal de servir diferents versions d'un mateix recurs (representat normalment per la seva URL). Normalment el user-agent (Navegador) pot, mitjançant l'ús de capçaleres HTTP, negociar amb el servidor quina versió del recurs desitja. És important destacar que la URL del recurs serà la mateixa per a les múltiples versions d'un mateix document.

A cada versió d'un mateix document l'anomenem representation.

La negociació de contingut s'utilitza per exemple en el cas de les API REST per tal de decidir el format de la resposta per exemple decidir entre una resposta en format JSON o XML.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation

Normalment hi ha dos formes/mecanismes d'implementar la negociació de continguts:

Resources:

Server-driven content negotiation

En aquest cas el user-agent utilitza capçaleres HTTP per indicar les preferències de l'usuari. El servidor utilitza aquesta informació com a pistes/hints per tal de decidir quina representació/versiódel recurs servir al user-agent. El algorisme utilitzat pel servidor no està especificat a l'estàndard HTTP i depèn de cada servidor (vegeu per exemple Apache [1]). Les capçaleres utilitzades per a la negociació de continguts són:

  • Accept: llista de mime-types preferits
  • Accept-Charset: Indica el tipus de charset. Es recomana l'ús de UTF-8 i per aquesta raó molts navegadors han abandonat l'ús d'aquest header
  • Accept-Encoding: indica els encoding acceptats.
  • Accept-Language: s'utilitza per definir els idiomes preferits mitjançant codis ISO. Vegeu locale
  • Accept-CH header: This is part of an experimental technology called Client Hints and currently implemented only in Chrome 46 and later The experimental Accept-CH lists configuration data that can be used by the server to select an appropriate response.

Laravel i content-negotation

Podem obtenir les capçaleres amb el mètode header del objecte REQUEST:

Route::get('/foo', function()
{
    $accept = request()->header('accept'); // application/json

    if( $accept === 'application/json' )
    {
        return ['foo' => 'bar']; // Returns JSON, thanks to Laravel Magic™
    }

    return view('foo.bar');
});

En el cas de Json de fet ja tenim un mètode wantsJson:

Laravel provides a nice, easy way to check if a request "wants json":


Route::get('/foo', function()
{

    // Look at this nice, friendly global helper function
    // Hello, global function! We sincerely love you with all our <3
    if( request()->wantsJson() )
    {
        return ['foo' => 'bar'];
    }

    return view('foo.bar');
});
public function wantsJson()
{
    $acceptable = $this->getAcceptableContentTypes();
    return isset($acceptable[0]) && Str::contains($acceptable[0], ['/json', '+json']);
}

HI ha altres mètodes interessant com:

Recursos:

Connexions persistents

HTTP 1.0: Si el client suporta connexions persistents ho ha d'indicar a la capçalera HTTP amb:

Connection: keep-alive

A partir del protocol HTTP1.1 és el comportament per defecte

https://upload.wikimedia.org/wikipedia/commons/d/d5/HTTP_persistent_connection.svg

Resources:

Content Security Policy

Vegeu Content Security Policy

Vegeu també

HTTP 2

Vegeu article HTTP 2

Enllaços externs