Scritto da
altg
utente che non utiene
il 2013-05-02 03:40:22.0 alle 2013-05-02 03:40:22.0
Trollate totali: 11540
Stavo cercando di capire la logica (apparentemente perversa) delle negoziazioni tra client e server secondo il protocollo HTTP/1.1 come da sezione 14.1:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.... 
dove spiega come dovrebbe essere interpretato l'Accept per il tipo di media che il client preferirebbe, via via scalando i q values verso tipi meno preferibili. Mi ci sono surriscaldato le rotelle a cercare di capire cosa, esattamente, vorrebbero che il server facesse, e non mi riesce di googlare (o arrivare a) un'interpretazione un po' piu` chiara del testo di quella pagina. La situazione mi appare confusa perche` se da un lato dice che si deve dare precedenza ai tipi piu` specifici (cioe` quelli con piu` parametri, e cosi` text/html ha la precedenza su text/*, e "text/html; level=1" ha la precedenza su entrambi), poi pero` nell'esempio successivo ha un formato che il server (nell'esempio) puo` gestire e che e`:
text/html; level=3
al quale viene attribuito un q value di 0.7 perche` e quello che l'accept header specifica per text/html, in assenza di un match esatto su "text/html; level 3". Lo stesso succede anche per l'immagine, nello stesso esempio: image/jpeg prende un q di 0.5 perche` e` quello di */*, cioe` "qualunque altra cosa", che pero` e` totalmente aspecifico, alla faccia della precedenza stabilita prima.
Sicche` cosa ho capito io: dovrebbe essere il q value attribuito dal client che ha la precedenza assoluta, e solo a parita` di q value la precedenza la si da` al tipo piu` specifico. Il che porta a possibilita` tipo questa:
accept: text/html; q=0.5, image/*; q=0.8, */*; q=0.9
supportati: text/html,image/jpeg,application/json
alla fine il server e` costretto (o no?) a scegliere application/json, perche` (porca miseria) */* ha il q value piu` alto. Sicche` un'accept del genere significherebbe, piu` che un "preferisco questi formati", un "detesto questi formati".
Boh.

dove spiega come dovrebbe essere interpretato l'Accept per il tipo di media che il client preferirebbe, via via scalando i q values verso tipi meno preferibili. Mi ci sono surriscaldato le rotelle a cercare di capire cosa, esattamente, vorrebbero che il server facesse, e non mi riesce di googlare (o arrivare a) un'interpretazione un po' piu` chiara del testo di quella pagina. La situazione mi appare confusa perche` se da un lato dice che si deve dare precedenza ai tipi piu` specifici (cioe` quelli con piu` parametri, e cosi` text/html ha la precedenza su text/*, e "text/html; level=1" ha la precedenza su entrambi), poi pero` nell'esempio successivo ha un formato che il server (nell'esempio) puo` gestire e che e`:
text/html; level=3
al quale viene attribuito un q value di 0.7 perche` e quello che l'accept header specifica per text/html, in assenza di un match esatto su "text/html; level 3". Lo stesso succede anche per l'immagine, nello stesso esempio: image/jpeg prende un q di 0.5 perche` e` quello di */*, cioe` "qualunque altra cosa", che pero` e` totalmente aspecifico, alla faccia della precedenza stabilita prima.
Sicche` cosa ho capito io: dovrebbe essere il q value attribuito dal client che ha la precedenza assoluta, e solo a parita` di q value la precedenza la si da` al tipo piu` specifico. Il che porta a possibilita` tipo questa:
accept: text/html; q=0.5, image/*; q=0.8, */*; q=0.9
supportati: text/html,image/jpeg,application/json
alla fine il server e` costretto (o no?) a scegliere application/json, perche` (porca miseria) */* ha il q value piu` alto. Sicche` un'accept del genere significherebbe, piu` che un "preferisco questi formati", un "detesto questi formati".
Boh.
-
$ranona @ 2013-05-02 03:40:22.0 di altg
-
■ @ 2013-05-02 04:02:28.0 di altg
-
■ @ 2013-05-02 16:25:39.0 di altg
-
-
■ @ 2013-05-02 03:58:53.0 di exsinistro
-