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:
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:
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:
> 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:
> 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:
> 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:
> > Hi All,
> > 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.
> > 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:
> > 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:
> > 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?).
> > > 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.
> > > 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:
> > > 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:
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.
> 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.
I've created #4148 a while ago. There are two distinct IE bugs it solves:
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
On Apr 7, 5:57 pm, "SmileyChris" <smileych...@gmail.com> wrote:
> > 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?).
> > > 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.
> > > 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:
> > > 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:
On 14 июн, 22:09, Mikko Hellsing <m...@sorl.net> wrote:
> try this: 'inline; filename=filename.pdf' > ...that is to use inline instead of attachment
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.
