Files caricati a S3 con S3BotoStorage finire con invalidamente sfuggito contenuti di tipo meta dati

Question

facepalm UPDATE: Risulta avevo dimenticato/trascurato il fatto che stavo usando una vecchia forcella di S3BotoStorage da https://github.com/gtaylor/django-athumb come il mio di archiviazione predefinito (anche sebbene avessi installato i django-storages). L'attuale versione di django-storages non soffre di questo problema. Il problema era che le intestazioni del tipo di contenuto erano unicode quando hanno colpito boto e boto escapes unicode utilizzando urllib.quoteplus prima di inviarlo ad AWS. Questo non è in realtà un errore di Boto poiché le intestazioni devono essere convertite in stringhe non Unicode in qualche modo per HTTP. Per un'analisi più approfondita, vedere https://github.com/boto/boto/issues/1669.

domanda iniziale

Sto usando django_storage's S3BotoStorage in combinazione con un FileField per caricare i file su Amazon S3. Ecco il mio campo:

downloadable_file = FileField(max_length=255, upload_to="widgets/filedownloads", verbose_name="file") 

In impostazioni:

DEFAULT_FILE_STORAGE = 'storages.backends.s3boto.S3BotoStorage' 

Tutto funziona per quanto riguarda il caricamento/scaricamento va.

Tuttavia, i file vengono memorizzati nel mio bucket con un tipo di contenuto non corretto. Quando guardo i metadati per i file nella mia console AWS S3, il Content-Type del file viene visualizzato come "application% 2Fpdf" invece di "application/pdf" che dovrebbe essere.

Nel caso in cui dicono che non dovrebbe importare, esso non importa. Il lettore di PDF integrato di Google Chrome si bloccherà su PDF con un tipo di contenuto non valido e un cliente me lo ha segnalato.

Here's an example of a file uploaded through django-storages/boto. Se si utilizza il lettore di PDF integrato di Chrome, presumo che si blocchi, come fa per me e il cliente che ha segnalato questo. Se stai usando un browser non-chrome, o il plugin Adobe, o il download del file sul disco, probabilmente starai bene.

Se cambio manualmente i metadati del tipo di contenuto tramite la console AWS in "application/pdf" (una delle opzioni standard che fornisce), allora va bene.

Presumo che questo sia un bug con qualcosa di interno nel modo in cui boto costruisce il documento della politica AWS per caricare il file, dal momento che non sto facendo nulla al di fuori dell'uso standard qui. Tuttavia, ho fatto un passo attraverso il codice boto e non riesco a trovare dove effettivamente fa l'escape.

Qualcuno può suggerire un lavoro in giro o guidarmi al codice incriminato in boto, così posso correggerlo e inviare una richiesta di pull?

boto == 2.9.5 django-depositi == 1.1.8

Answer 1

Il problema era che stavo usando una versione bifronte/obsoleta di archivi django che non convertivano correttamente intestazioni di tipo contenuto in stringhe da unicode prima di inviarle a boto, che converte stringhe unicode in stringhe ascii (come richiesto per HTTP intestazioni) utilizzando il meccanismo di escape di urllib quoteplus. Il problema è stato risolto passando alla versione corrente di django-storages.

Per un'analisi più dettagliata del problema si veda: https://github.com/boto/boto/issues/1669#issuecomment-27132112

Answer 2

Non è una risposta diretta alla sua domanda, ma forse una soluzione utile. Stavo riscontrando problemi nell'utilizzo di django-storages con S3. Ho finito per provare cuddly-buddly e sono stato abbastanza soddisfatto. L'autore lo ha basato sul modulo S3 di django-storages e ha aggiunto un bel numero di correzioni. Ho sfogliato i commit coccolosi e sono state apportate alcune modifiche all'intestazione del tipo di contenuto, ma non riesco a testare con i caricamenti PDF senza impostare un nuovo progetto django. Tuttavia, posso verificare che tutti i miei file caricati tramite Django non abbiano barre storpiate nel campo del tipo di contenuto nei metadati S3.

Se per qualche motivo non è possibile passare a coccole per test, fammi sapere e cercherò di configurare un semplice progetto Django per caricare alcuni PDF.