| Mara's dad |
Pour le reset() je n'y ai pensé que lorsque j'ai lu le source de la classe Response de coyote.
Ca m'a semblé une bonne idée de contournement sur le moment (en attendant une correction du bug), mais maintenant, après avoir lu les specs sur les JSPs, je sais que c'est pas un truc à faire. Sauf pour test, avant d'écrire la servlet qui va bien, et à condition d'utiliser coyote :D
Cependant, il me semble qu'il reste une faiblesse dans tomcat : getWriter() est appelé très tard, et rien n'empèche d'utiliser getOutputStream() et donc de faire du détournement de servlet :D
Lundi je poste le message suivant sur le bugzilla de tomcat.
Citation :
OK, I read the "JavaServer Pages Specification" and it's clear that JSPs are servlets only designed to send TEXT data.
Trying to send a PDF or other binary data via a JSP should not be done.
A servlet should be written for this kind of things.
The workaroud 'response.reset()' should not be used in a production environment. It works with the actual Coyote implementation, but nothing can guarantee that others implementation will accept it.
In facts, the getOutputStream() method should not be allowed in a JSP.
The getWriter() method should be called() as soon as possible in the generated java code of the JSP. Then a call to getOutputStream() would result in a IllegalStateException.
Regards
|
J'espère que cette fois, ceux qui sont confrontés à ce problème comprendrons que ce n'est pas un bug mais qu'une JSP n'est pas fait pour envoyer du binaire.
PS: Si j'ai bien compris, il y avait quand même un bug (corrigé depuis) dans tomcat 4.1.29 qui faisait que le charset ISO-8859-1 était envoyé avec le Content-Type pour toute servlet. |
