Mostra notizie nelle discussioni
  • Avatar
    ☺
    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
    $ranona
    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.
    • Avatar
      ☺
      Scritto da
      il 2013-05-02 03:58:53.0 alle 2013-05-02 03:58:53.0
      Trollate totali: 17613
      Re: $ranona
      Scritto 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. Newbie, inesperto
      Everyone has the right to my opinion!
    • Avatar
      ☺
      Scritto da
      altg
      utente che non utiene
      il 2013-05-02 04:02:28.0 alle 2013-05-02 04:02:28.0
      Trollate totali: 11540
      Re: $ranona
      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. Triste

      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". Fantasma
      • Avatar
        ☺
        Scritto da
        altg
        utente che non utiene
        il 2013-05-02 16:25:39.0 alle 2013-05-02 16:25:39.0
        Trollate totali: 11540
        Re: $ranona
        > 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. Triste
        >
        > 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". Fantasma

        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".
<softv>

Pagina generata in 78 millisecondi

Utenti attivi: 9 nell'ultimo minuto, 20 negli ultimi cinque minuti, 35 negli ultimi 15 minuti