Tamas Szabo wrote:
That's interesting, I didn't know that PDF works just like HTML in this
matter.
A coworker wrote the PDF generator so I'm not sure about this, but I tend to
think that the problem is not caused by this, because then I would get the
confirmation box when I make a GET request too...
He probably wrote it on top of iText, or some similar package though,
right? If not you should probably smack him next time you see him :)
> The app is a Struts app and the cache headers are set.
I can try to do this (what is this JWP? hehe), but do you thin that iw
would be different
for GET and POST requests?
I wouldn't expect so, but I know your seeing a difference between POST
and GET. That I wouldn't have expected. Actually, I'm not 100% sure
what my app is doing frankly, I'm pretty sure a GET, but I'm going to
have to check on Monday,
So it is a GET request? :-)
Yep, that's what I meant, I'm not really sure... I haven't looked at
that part of the code in a long time, but I'd actually be surprised if
it WASN'T a GET.
I tested this only with open in browser setting.
Yeah, I'd say flip it and see if you see any difference. It wouldn't
surprise me if you do.
I like the Ethereal idea I will try this at first on Monday probably.
And after that I can try to send back another bytestream(not a PDF) to see
if the PDF plug-in is the source of the problem or not?
That's definitely a good idea too. Probably the easiest test would be
to stream a GIF off the file system, since you can be all but certain
any browser isn't going to have a problem with that.
One other problem I saw a lot of had to do with network proxies...
that's where Etheral might help... we saw some really wacky things that
were caused by the proxies, so if you have any in the mix I'd cast a
very suspicious eye on them.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
