Sembra che il download delle immagini nelle onebox sia rotto. Forse un recente regression causato da modifiche alle onebox o ai media sicuri. @vinothkannans Potresti dare un’occhiata per favore?
Esempio: Oneboxing di https://www.samsung.com/us/mobile/galaxy-z-flip non mostra un’immagine perché le immagini vengono caricate tramite HTTP.
Il problema è che, durante il download dell’immagine onebox dall’URL “http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg”, viene restituito il file in formato “.webp” (samsung-logo-191-1.webp). Di conseguenza, non riusciamo a scaricarlo poiché il formato “.webp” non è incluso nell’elenco delle estensioni consentite (authorized_extensions) nelle impostazioni del sito.
L’icona del sito non viene scaricata perché si tratta di un file “`.ico``. Dovremmo consentire i file “ico” nelle onebox per impostazione predefinita?”
Mi chiedo se il formato WebP sia presente solo a causa dell’uso del user agent di Chrome 
Non credo proprio. Restituisce un file webp anche quando lo scarico manualmente su Firefox.
Nella mia versione di Firefox (77.0.1 (64-bit) per MacOS), l’intestazione Accept nella richiesta per l’URL sopra è:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
(cioè, il browser richiede un’immagine webp, se disponibile)
Safari, invece, ha un’intestazione Accept di:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
e il server web Samsung restituisce un jpeg. L’Onebox viene visualizzato correttamente (con l’immagine) in Safari.
Samsung utilizza Akamai Image Manager per servire questi file.
Se invio un header Accept con il valore image/jpeg,image/gif, ricevo un image/jpeg, come previsto.
wget --header="Accept: image/jpeg,image/gif" http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
--2020-11-13 11:43:58-- http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
Resolving image-us.samsung.com (image-us.samsung.com)... 23.217.144.69
Connecting to image-us.samsung.com (image-us.samsung.com)|23.217.144.69|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 83094 (81K) [image/jpeg]
Saving to: 'samsung-logo-191-1.jpg.6'
Discourse tenta di recuperare l’immagine chiamando FileHelper.download, che a sua volta chiama FinalDestination.get, il quale alla fine richiede il file con un UserAgent di:
Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Quindi, se richiediamo la stessa immagine con lo stesso header Accept come sopra, ma aggiungendo anche quel user agent, otteniamo:
wget --header="Accept: image/jpeg,image/gif" --header="User-Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36" http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
--2020-11-13 11:52:50-- http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
Resolving image-us.samsung.com (image-us.samsung.com)... 23.217.144.69
Connecting to image-us.samsung.com (image-us.samsung.com)|23.217.144.69|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 45540 (44K) [image/webp]
Saving to: 'samsung-logo-191-1.jpg.10'
E viene restituito un image/webp. Sembra che stiano ignorando l’header Accept e stiano usando la propria logica per determinare il tipo di file migliore in base al user agent.
Apple non ha storicamente supportato webp, quindi proviamo con quello:
wget --header="Accept: image/jpeg,image/gif" --header="User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15" http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
--2020-11-13 12:27:02-- http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
Resolving image-us.samsung.com (image-us.samsung.com)... 23.217.144.69
Connecting to image-us.samsung.com (image-us.samsung.com)|23.217.144.69|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 83094 (81K) [image/jpeg]
Saving to: 'samsung-logo-191-1.jpg.16'
Successo!
Penso che si possa fare un argomento molto forte secondo cui il web server dovrebbe sempre rispettare l’header Accept e non cercare di essere più intelligente di esso. D’altra parte, qualcuno potrebbe sostenere che se si presenta una stringa di user agent specifica, ci si dovrebbe aspettare di comportarsi come quell’user agent (anche se lo spoofing dell’user agent non è raro e ha una varietà di utilizzi).
Come capita, Apple ha aggiunto il supporto webp a iOS14 (rilasciato di recente) e MacOS Big Sur (rilasciato ieri), quindi probabilmente dovremmo supportarlo (aggiungendolo come estensione consentita predefinita) e configurando ImageMagick per supportarlo (il che introdurrà una dipendenza da libwebp o simile) in modo da poter ottimizzare e ridimensionare, ecc.
Questo è un comportamento terribile da parte di Akami, uffa.
È banale modificare il nostro user agent fittizio? In ogni caso, non dovremmo fingere di essere Chrome 58, rilasciato nel 2017.
@eviltrout dovrebbe avere il quadro completo del motivo per cui Discourse finge e non utilizza un User Agent specifico solo per Discourse. Il mio ricordo vago è che, se non fingessimo, alcune persone ci impedirebbero di scaricare immagini e onebox. Potremmo:
Forse possiamo permettere una traduzione “trasparente” da WebP a JPEG dopo il download del file, in modo da poter ancora fare da proxy per immagini non compatibili se l’operatore del sito non offre un supporto completo (questo potrebbe essere utile con altri formati di immagine esotici).
Oppure semplicemente procediamo e supportiamo WebP di default, aggiungendolo a tutte le nostre impostazioni predefinite? (Mi chiedo se sia troppo presto)
La risposta è che, purtroppo, molti siti non forniscono il contenuto corretto a meno che la richiesta non sembri provenire da un browser. Sospetto che, se cambiassimo questo, la maggior parte delle fonti funzionerebbe bene, ma una o due si comporterebbero in modo strano.
Gli onebox sono spesso un grande gioco di “colpisci la talpa”. Risolvi un bug e un altro spunta da un’altra parte.
Ora che Apple sta cedendo e aggiungendo il supporto a Safari e iOS, sembra il momento giusto per farlo.
Il commit sopra citato ha aggiunto il supporto per i caricamenti .webp.
Dopo un po’ di sforzi per far rielaborare il post originale, sembra che questo problema sia ora risolto (cioè, il logo ‘Samsung’ è stato scaricato/cachato localmente).
Credo che questo problema possa essere considerato risolto.