Hi,

I am trying to stream a PDF to the browser from a servlet. In the servlet I 
have added appropriate Content type like application/pdf. This response head
er is working fine on the test servers without HTTP Server. But, on the clie
nt side, there is a IBM HTT
P server and WebSphere App Server combination. When I get the response there
, I am getting the gzip encoded pdf stream along with cache-control: no-cach
e header. We have not written these headers in our servlet, I am sure this i
s coming from the IBM HTTP
Server. Both of these headers are causing problem -
GZIP causes a racing condition between Internet Explorer and Adobe Acrobat (
Ver 6 and 7), giving an error "File is already in use by another user". By m
aking Internet explorer to use HTTP 1.0, GZIP goes off because Accept-Encodi
ng will not go in request h
eader from Browser for HTTP 1.0. But, the cache-control remains, causing pro
blem - "Internet explorer cannot download TestPDFServlet from localhost"(ser
ver name) dialog, as per my understanding this comes when byte stream comes 
to browser and there is no-
cache header.

How do we disable both of these option at the server side (atleast cache). F
ollowing is the response header I am getting -

HTTP/1.1 200 OK
Date: Mon, 30 Jan 2006 11:31:37 GMT
Server: IBM_HTTP_Server/2.0.47.1 Apache/2.0.47 (Unix) DAV/2
Set-Cookie: CLT=129.42.125.193.1138620697393388; path=/
Set-Cookie:  JSESSIONID=00002QWNuS9v3NQBcFoV_Ww1LL6:1
0h9so4kj;Path=/
Cache-Control: no-cache="set-cookie,set-cookie2"
Expires: Thu, 01 Dec 1994 16:00:00 GMT
widget: printLossContact
Vary: Accept-Encoding
Content-Encoding: gzip
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1

text/html is again coming from some server setting. This is still ok since A
crobat 7 still opens by understanding the byte. This we have tested here.

Any help is really appreciated.

[ Post a follow-up to this message ]

Is this MIME type (pdf) configured in WAS? Check in admin console or the
plugin configuration.

Sunit

<dinakargop@yahoo.com> wrote in message
news:1457124596.1139393981961.JavaMail.wassrvr@ltsgwas007.sby.ibm.com...
> Hi,
>
> I am trying to stream a PDF to the browser from a servlet. In the servlet
> I have added appropriate Content type like application/pdf. This response
> header is working fine on the test servers without HTTP Server. But, on
> the client side, there is a IBM HTTP server and WebSphere App Server
> combination. When I get the response there, I am getting the gzip encoded
> pdf stream along with cache-control: no-cache header. We have not written
> these headers in our servlet, I am sure this is coming from the IBM HTTP
> Server. Both of these headers are causing problem -
> GZIP causes a racing condition between Internet Explorer and Adobe Acrobat
> (Ver 6 and 7), giving an error "File is already in use by another user".
> By making Internet explorer to use HTTP 1.0, GZIP goes off because
> Accept-Encoding will not go in request header from Browser for HTTP 1.0.
> But, the cache-control remains, causing problem - "Internet explorer
> cannot download TestPDFServlet from localhost"(server name) dialog, as per
> my understanding this comes when byte stream comes to browser and there is
> no-cache header.
>
> How do we disable both of these option at the server side (atleast cache).
> Following is the response header I am getting -
>
> HTTP/1.1 200 OK
> Date: Mon, 30 Jan 2006 11:31:37 GMT
> Server: IBM_HTTP_Server/2.0.47.1 Apache/2.0.47 (Unix) DAV/2
> Set-Cookie: CLT=129.42.125.193.1138620697393388; path=/
> Set-Cookie:  JSESSIONID=00002QWNuS9v3NQBcFoV_Ww1LL6:1
0h9so4kj;Path=/
> Cache-Control: no-cache="set-cookie,set-cookie2"
> Expires: Thu, 01 Dec 1994 16:00:00 GMT
> widget: printLossContact
> Vary: Accept-Encoding
> Content-Encoding: gzip
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Transfer-Encoding: chunked
> Content-Type: text/html; charset=ISO-8859-1
>
> text/html is again coming from some server setting. This is still ok since
> Acrobat 7 still opens by understanding the byte. This we have tested here.
>
> Any help is really appreciated.
>

[ Post a follow-up to this message ]