-
$ranonaScritto daaltgutente che non utieneil 2013-05-02 03:40:22.0 alle 2013-05-02 03:40:22.0Trollate totali: 11540Stavo 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.-
Re: $ranonaScritto da: altg
> 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.
Adesso vado a dormire, domani ... più tardi, moolto più tardi ci penso. ci penso.
Everyone has the right to my opinion!
-
Re: $ranonaScritto daaltgutente che non utieneil 2013-05-02 04:02:28.0 alle 2013-05-02 04:02:28.0Trollate totali: 11540Ah ok, ho trovato qualcosa.
Qui conferma quel che avrei capito dalle specifiche, cioe` la precedenza va al q value, poi alla specificita` del formato, e poi passa in rassegna i vari headers spediti dai vari browsers e dice che ho buttato via tre ore a preoccuparmi dell'accept header:
http://www.gethifi.com/blog/browser-rest-http-acce...
Che bello.
Pero` ormai il parser l'ho scritto e me lo tengo. Puo` consentire anche tutti i paradossini carini come appunto quello della de-preferenza alzando il valore di q di un tipo meno specifico, ovvero "qualunque cosa e` meglio di questi formati". Ma tanto, principalmente lo usero` per scegliere come mostrare un errore, piu` che le varie versioni (inesistenti) di un documento che il "client o lo accetta cosi` com'e` o s'attacca".
-
Re: $ranonaScritto daaltgutente che non utieneil 2013-05-02 16:25:39.0 alle 2013-05-02 16:25:39.0Trollate totali: 11540> Ah ok, ho trovato qualcosa.
>
> Qui conferma quel che avrei capito dalle specifiche, cioe` la precedenza va al q value, poi alla specificita` del formato, e poi passa in rassegna i vari headers spediti dai vari browsers e dice che ho buttato via tre ore a preoccuparmi dell'accept header:
> http://www.gethifi.com/blog/browser-rest-http-acce...
>
> Che bello.
>
> Pero` ormai il parser l'ho scritto e me lo tengo. Puo` consentire anche tutti i paradossini carini come appunto quello della de-preferenza alzando il valore di q di un tipo meno specifico, ovvero "qualunque cosa e` meglio di questi formati". Ma tanto, principalmente lo usero` per scegliere come mostrare un errore, piu` che le varie versioni (inesistenti) di un documento che il "client o lo accetta cosi` com'e` o s'attacca".
Uppete.
Comunque che ne pensano gli esperti networkari locali?
Non e` che ho capito male qualcosa?
Se si`, premetto che l'accept della risposta e` il seguente:
Accept: answer/circumstantiated, answer/sax-like; q=0.1
dove per risposta sax-like s'intende "hai capito male".
-
-