Comment retourner les fichiers statiques en passant par une vue en django?

J'ai besoin de retourner les fichiers css et js fichiers selon la logique spécifique. Clairement, statique servir n'effectue pas ce dont j'ai besoin. J'ai une vision, dont la méthode de rendu utilise la logique pour trouver le bon fichier, mais puis-je le retourner. Techniquement, je peux juste lire le fichier et de le ranger dans un objet HttpResponse avec le bon type mime, mais je me demandais si il y avait une meilleure stratégie. (comme fpassthru() en php)

Qui est de ne pas faire ce pour quoi vous avez besoin, serveur de fichiers statiques de servir, ou django.views.static.serve ?
aucun des deux 🙂
en fait, une question de grammaire. est-il "ni de" ou "les deux" ?
Mmh, c'est là où je suis un peu confus. Voyez-vous, dans votre question, vous dites que vous pouvez fondamentalement lire le fichier et de le ranger dans un HttpResponse. Donc je suis en supposant que ces fichiers existent comme (ie: pas généré de façon dynamique) quelque part sur votre système de fichiers. Ce que vous empêcher de les servir directement avec le serveur? Ou ai-je raté quelque chose?
Je suppose aucun des deux, aucun d'eux 🙂

OriginalL'auteur Stefano Borini | 2010-02-19

  1. 17

    C'est ce que j'ai utilisé:

    test_file = open('/home/poop/serve/test.pdf', 'rb')
response = HttpResponse(content=test_file)
response['Content-Type'] = 'application/pdf'
response['Content-Disposition'] = 'attachment; filename="%s.pdf"' \
                                  % 'whatever'
return response
    J'avais besoin de la 'rb' mode sur la fonction open (), ou de ce code foiré mes fichiers pdf. C'est des matchs le code utilisé dans django/views/static.py.
    Il me semble que cela entraîne l'ensemble du fichier à charger en mémoire . N'est-ce pas?
    vous pouvez passer un itérateur pour HttpResponse au lieu de cela, j'ai modifié la réponse pour en tenir compte.
    Merci!!!! J'ai remplacé urllib2.urlopen(url_path).read() pour open(path) pour permettre un passe-vue, servant des pdf partir site externe: [1] url = "https://s3.amazonaws.com/bucketname/path-to-external-file.pdf" [2] import urllib2 [3] test_file = urllib2.urlopen(url).read() [4] response = HttpResponse(content=test_file) [5] response['Content-Type'] = 'application/pdf' [6] response['Content-Disposition'] = 'attachment; filename="%s.pdf"' % 'whatever' [7] return response

    OriginalL'auteur Uku Loskit

  2. 8

    Ce logiciel de serveur web que vous utilisez?

    Au moins pour Apache et NginX, il y a un module vous permettant d'utiliser la X-SendFile en-tête HTTP. Le site web de NginX dit Lighty pouvez le faire, aussi.

    Dans votre enveloppe de vue:

    ...

abspath = '/most_secret_directory_on_the_whole_filesystem/protected_filename.css'

response = HttpResponse()
response['X-Sendfile'] = abspath

response['Content-Type'] = 'mimetype/submimetype'
# or let your webserver auto-inject such a header field
# after auto-recognition of mimetype based on filename extension

response['Content-Length'] = <filesize>
# can probably be left out if you don't want to hassle with getting it off disk.
# oh, and:
# if the file is stored via a models.FileField, you just need myfilefield.size

response['Content-Disposition'] = 'attachment; filename=%s.css' \
    % 'whatever_public_filename_you_need_it_to_be'

return response

    Alors vous pouvez vous connecter à la vue via http://mysite.com/url_path/to/serve_hidden_css_file/.

    Vous pouvez l'utiliser n'importe quand vous avez besoin de faire quelque chose sur un fichier demandé qui ne doivent pas être directement accessibles aux utilisateurs, comme la limitation qui peut y avoir accès, ou de comptage des demandes pour les stats, ou quoi que ce soit.

    Pour Apache: http://tn123.ath.cx/mod_xsendfile/

    Pour NginX: http://wiki.nginx.org/NginxXSendfile

    OriginalL'auteur Geradeausanwalt

  3. 6

    Pourquoi n'utilisez-vous pas de Django staticfiles à l'intérieur de votre point de vue

    from django.contrib.staticfiles.views import serve

...
def view_function(request):
   return serve(request, 'absolute_path_to_file_name')
    Le docs dire: "Attention. Ce point de vue ne fonctionnera que si le DÉBOGAGE est Vrai. C'est parce que ce point de vue est d'une inefficacité flagrante et probablement d'insécurité. Ce n'est prévue que pour le développement local, et ne doit jamais être utilisé dans la production."

    OriginalL'auteur Gunnar Scherf

  4. 1

    Passer un itérateur (comme le résultat de open()) à la HttpResponse constructeur.

    OriginalL'auteur Ignacio Vazquez-Abrams

  5. 1

    Pourquoi pas le retour d'un HttpResponseRedirect à l'emplacement de le bon fichier statique?

    parce que le fichier n'est pas directement accessible.

    OriginalL'auteur Daniel Roseman

  6. 1

    Servir des fichiers directement à partir d'un point de vue est très lent. Si vous êtes à la recherche pour le fichier normal de servir le voir, cette question: Ayant Django servir les fichiers téléchargeables

    Très facilement de servir des fichiers par le biais de vue (à des fins de débogage, par exemple) continuer la lecture.

    # In your urls.py:
url(r'^test-files/(?P<name>.+)/$', views.test_files, name='test_files'),

# In your views.py:
from django.http.response import HttpResponse
from django.views.decorators.csrf import csrf_exempt

@csrf_exempt # (Allows file download with POST requests, can be omitted)
def test_files(request, name):
    if name == "myxml":
        fsock = open("/djangopath/data/static/files/my.xml", "rb")
        return HttpResponse(fsock)

    Ceci vous permet de télécharger le fichier à partir de: http://127.0.0.1:8080/app/test-files/myxml/

    OriginalL'auteur Mikael Lindlöf

  7. -1

    Il devrait être un gaspillage d'utiliser django pour servir du contenu statique (pour ne pas mentionner, de plusieurs ordres de grandeur plus lent).

    Je préfère convertir la vue dans un contexte de processeur et utiliser les variables dans les modèles pour trouver ce qui bloque à inclure.

    c'est exactement ce que je veux m'éloigner de. Je suis déjà, y compris le truc, avec le résultat que le css et le js fichiers sont codés en dur dans le fichier html, la prévention de toute forme de mise en cache (depuis la page dans son ensemble est réputé pour changer). Je veux être en mesure d'expédier le js et le css, mais depuis cet envoi est dépendante sur les plugins de mon application qui sont disponibles, j'ai besoin de réaliser une certaine logique avant l'envoi du fichier.
    Tu veux dire la prévention de toute forme de Django mise en cache? Parce que d'avoir le css & js comprend codée en dur dans le template de ne pas arrêter le navigateur de l'utilisateur à partir de la mise en cache. Je ne suis pas clair sur ce qu'est le véritable problème. Il semble que vous rencontrez des difficultés de mise en cache de la page entière en raison de la dynamique comprend. Pourquoi ne pas mettre en cache le reste de la page et de laisser le navigateur/ de votre serveur web faire le reste (ce qui est son travail de toute façon)?
    Ce serait faire un grand commentaire ou une mise en garde après une vraie réponse.

    OriginalL'auteur Lakshman Prasad