I found that Django can not serve PDF files from view, and I feel this
is wrong and must be fixed, so I try to raise this topic now.
Problem description:
We've build e-commerce site which sells PDF files as well. For obvious
reasons I can not put all our PDF files as static files on media
server.
I have also found nice guide and followed it:
http://www.djangoproject.com/documentation/outputting_pdf/
Actual code I've used is this one:
http://dpaste.com/7959/
All worked well, we have installed new site yesterday, and got
numerious number of complaints from our users. Tracking down the
problem we've found that it is IE specific, well known and mentioned
on Microsoft support site:
http://support.microsoft.com/kb/824847/en-us?spid=8722&sid=global
I've asked on IRC, people helped me and pointed out that I should
write middleware to fix this problem. Btw, big thanks to 'axiak' from
#django IRC by helping to resolve problem in fast manner:
Now, I am curious, is this normal that to serve PDF file it is
required to write middleware?
Alex
To be honest, I find Django tries very hard to be compliant with W3C
(adding things in favor of WCAG, using XHTML when possible, etc). This
usually isn't a problem because most browser-compatibility things can
be changed in the template layer.
The reason custom middleware had to be written to solve this problem
is a bug in IE's (mis)use of HTTP. Not HTML (EMCAScript/CSS...), mind
you, but HTTP. Microsoft has created a page that seems to be a bug-
report page, not a "this is how we do HTTP" page. AFAIK, this is the
only example I've seen of browser incompatibilities causing problems
in the HTTP layer, does anybody else know of any others?
Honestly, I am surprised no one else has seen this bug. If they have,
I am curious what the solutions have been (don't use any of the number
of Django middleware that use Vary?).
Cheers,
Mike Axiak
On Apr 5, 2:35 pm, "alex.v.ko...@gmail.com" <alex.v.ko...@gmail.com>
wrote:
On Apr 6, 7:07 am, "Mike Axiak" <mcax...@gmail.com> wrote:
> Well I can't help but post a more complete solution (;-)) located athttp://www.djangosnippets.org/snippets/157/.
I'd suggest that this is probably important enough for core addition.
One could whine that it's IEs fault but that doesn't solve the problem.
response = HttpResponse(pdf, "application/pdf")
response['Content-Disposition'] = 'attachment; filename=%s.pdf' %
filename
return response
which works for me. I'd be interested to know if it works for
others..
Cheers,
-Curt
I use a similar approach to output PDF's on our intranet applications
and I've got no complaints from users (which use IE although they know
they **must not** use it).
So I can assume that the Content-Disposition does the trick for me too.
On May 21, 2:55 am, Curtis <curtis.thomp...@gmail.com> wrote:
> An alternate solution:
>
> response = HttpResponse(pdf, "application/pdf")
> response['Content-Disposition'] = 'attachment; filename=%s.pdf' %
> filename
> return response
>
> which works for me. I'd be interested to know if it works for
> others..
This is odd. I've been able to repeat the problem with no problems --
do you have no-cache and no vary headers set? There are a whole slew
of cases where different sets of headers will just force a blank white
page in IE. The middleware prevents that, but it's not needed for a
few simple cases.
Hope this helps,
Mike Axiak
1) Vary headers set for files that get opened in embedded applications
(MS Help, Acrobat, etc).
2) Any sort of no-caching headers for anything with content-
disposition. IE's stance on this is that if you specify that something
can't be cached, you shouldn't be allowed to download it. I'm not sure
this is a feature, but I'm not sure how obvious it is we want to "fix"
it.
-Mike
we tried 'inline', too, and it does not work.
Only solution which has been explained in original post fixed the
problem, and our site works well
since April, 5 when I have solved the problem (with Mike help) and
posted this topic start message.