Lista di errori. Anche senza il testo dell'esame, la lettura è istruttiva.
- L'URL relativo sports/newIndex.html contenuto in www.org.com/sports/index.html equivale a www.org.com/sports/sports/newIndex.html; non equivale a www.org.com/sports/newIndex.html.
- Qualcuno ha inserito nel conteggio delle connessioni TCP anche quelle che il browser apre con il server DNS. Ho considerato queste risposte corrette, anche se non avrei dovuto. Le interazioni DNS avvengono praticamente sempre su UDP, le interazioni TCP sono usate solo per (alcune) interazioni primario-secondario. Inoltre, noi non abbiamo visto come DNS usa TCP: non abbiamo cioè detto che DNS usi una connessione TCP per ogni coppia request-response.
- Request "www.org.com A ?", Response "www.org.com NS ns.org.com"+"ns.org.com A IP1". Bene, adesso con chi si collega il browser? Con IP1? Uno svolgimento di questo genere, specialmente con la premessa "suppongo che il server supporti risposta ricorsiva" (cioè, il server trova il RR che mi occorre), significa non avere capito nulla del DNS.
- Testo: "Per ogni pagina menzionata nell'esercizio, fornire il conteggio al termine dell'interazione". Svolgimento "Riceve 5 HTTP request, una per ogni documento html visualizzato". Ma quanti caspita sono questi documenti? 1? 2? o 5? E' evidente che la risposta non contiene questa informazione, richiesta nel testo. Inoltre, se ad esempio i documenti fossero 3, il conteggio è 3+1+1 oppure 1+3+1 oppure 1+1+3? Quando dico che è fondamentale leggere il testo probabilmente risulto pedante e antipatico, ma se lo dico un motivo c'è.
- Testo "Descrivere tutta la sequenza di richieste e risposte DNS inviate e ricevute dal browser". Svolgimento:
Ora, tralasciamo pure il fatto che se si chiede una sequenza allora si vuole vedere l'ordine dei messaggi e in questo disegno questa informazione è completamente assente; tralasciamo anche che abbiamo detto e ripetuto una infinità di volte che in questi esercizi occorre fornire i RR e in questo disegno questa informazione è completamente assente. Facciamo l'interpretazione più plausibile: browser invia una request di tipo A a www.org.com per trovare l'indirizzo di quest'ultimo (?????): ma se dovete chiedere il numero telefonico a un amico telefonate a quell'amico????
- "Suppongo main.gif sia un URL relativo al server www.org.com". Esempio di confusione tra mele e scarpe: Un URL relativo a un server? Un URL relativo è relativo ad un altro URL.
- Non so quante volte l'ho ripetuto: se devo trovare l'indirizzo associato al nome sgddhshfk allora faccio una domanda " sgddhshfk A ?". NON faccio la domanda "sgddhshfk NS ?". Non ha alcun senso. Peggio ancora, qui termino con l'indirizzo del name server della zona a cui appartiene sgddhshfk, NON termino con l'indirizzo di sgddhshfk. Con chi si collega adesso il browser?
- Lo header Referrer deve essere presente anche nelle richieste inviate a causa della pressione di un link. Non solo in quelle inviate per prelevare immagini o iframe.
- "Non realizzabile perché due server non possono essere in esecuzione sullo stesso nodo". Per quale motivo? Chi l'ha mai detto? Non ha il minimo senso. Devo ancora decidere come valutare questo caso. Correggerò il resto del compito e poi deciderò.
- Se il sito adclick.com è sul sito di web hosting catchit.net, perché mai il browser deve di sua spontanea iniziativa inviare la DNS request "catchit A ?" ? Come fa il browser a sapere che adesso c'è di mezzo catchit.net? Inoltre, perché mai il valore dello header Host adesso dovrebbe essere catchit.net? Se così fosse allora tutti gli URL cambierebbero (il sito non potrebbe cioè chiamarsi adclick.com).
- Web hosting, custom domain: se un sito di nome N1 viene ospitato dal servizio di web hosting di nome N2, nel DNS viene inserito il record N1 CNAME N2. Ma gli header Host continuano ad avere N1. Non hanno N2. Se avessero N2 allora gli URL assoluti non avrebbero nulla a che vedere con N1.
- Request per URL main.gif?ID=3456abc e response contiene l'immagine richiesta. "Qui la sessione scade perché si trasporta un documento senza link da modificare" E perché mai? Una sessione scade se l'applicazione decide di farla scadere oppure se non si ricevono request con l'id di quella sessione per un intervallo di tempo predefinito. Non scade perché non si è avuta l'opportunità di scrivere l'id di quella sessione nel documento. Inoltre, ammettiamo pure che la sessione scada; le richieste successive inviate dal browser seguendo link già presenti sul browser, conterranno comunque l'id della sessione. Non è che il browser modifica gli URL che si trovano nei documenti che sta visualizzando (oltretutto in base a funzionalità telepatiche: come farebbe il browser a sapere che il server ha deciso di fare scadere la sessione?)
- Set-Cookie nelle request e non nelle response lo dovevo ancora vedere.
- Response con header, LV e poi "documento che dice al browser che la cache è validated quindi non necessita di reinviarlo". Quando mai abbiamo visto un documento che fornisce informazioni al browser? Sono i response header che forniscono informazioni al browser, e possono farlo perché hanno nomi predefiniti, valori predefiniti, significato predefinito. Come fa un documento ad informare il browser di qualcosa? In quale lingua dovrebbe essere scritto? Che parole dovrebbe usare?
- Come fa una response ad avere Content-type: "Img" e a trasportare un documento "<iframe SRC="...">"? E perché mai poi non viene prelevato il documento riferito dall'attributo SRC dell'iframe?
- "La BASIC authentication non permette il mantenimento delle sessioni con URL rewriting". Perché mai? L'unica cosa di cui abbiamo parlato e che gli assomiglia lontanamente è questa: la BASIC authentication si può usare con o senza sessioni (non perché lo dico io, ma perché è così); e che negli esami deve essere usata con le sessioni, a meno che sia impossibile (perché lo dico io). Cosa c'entra questo con la impossibilità di mantenere le sessioni con URL rewriting?
- Si scrive cache. Non cash. Si pronunciano più o meno nello stesso modo (io non sono in grado di pronunciarli in modo diverso). Ma sono cose molto diverse. Ai fini degli esami faccio finta di nulla, ma scrivere una cosa del genere in un documento tecnico importante può avere effetti spiacevoli (= farsi ridere dietro; le cache sono un concetto usato in moltissimi settori dell'informatica radicalmente diversi tra loro; noi ne abbiamo visti solo due ma sono tanti, date un'occhiata a Wikipedia).
- Stime per il numero di connessioni TCP che hanno solo il minimo o solo il massimo sono da considerarsi, nel migliore dei casi, solo parzialmente corrette.
Come interpretare questo disegno? Mi pare ci sia una sola interpretazione possibile: per trovare il numero di telefono di un amico devo telefonare a quell'amico. (www.org.com era disegnato nello stesso modo).- Una quantità incredibile di persone ha scritto la response alla get della home page con solo uno dei due header necessari: Cache-control: must-revalidate; Etag: qualche-id; Capisco che uno non li metta tutti, ma metterne solo uno dei due ha davvero poco senso.
