> Yes, it can be done with a simple . See earlier message in this
> thread for details, or follow the link to the Tomcat bug database in my
> previous message.
I missed that thread, but this is good to know. Thanks!
>Keep in mind, this is not just a problem > with pdf files
> Yes, it can be done with a simple . See earlier message in this
> thread for details, or follow the link to the Tomcat bug database in my
> previous message.
I missed that thread, but this is good to know. Thanks!
>Keep in mind, this is not just a problem > with pdf files
Frank W. Zammetti wrote:
... The point being that even if you can disable the option in Tomcat
(and I'm not sure you can?)
Yes, it can be done with a simple . See earlier message in this
thread for details, or follow the link to the Tomcat bug database in my
previous message.
FYI, I wo
I realize this is the Tomcat list, but I suspect many people here use
Struts in developing their apps... I think it is worth noting that
Struts provides a "nocache" switch for the Request Processor that does
the same thing (setting the no cache headers). I found this out the
hard way about tw
Maybe IEs implementation existed before HTTP 1.1 and before the
"no-store" option was introducted, which seems to clarify the matter
of what isn't allowed to be stored to disk, there is nothing else in
the specififcation that mandates the user-agent or cache can not (in
the process of serving
Mark Leone wrote:
The point is that IE is not providing the resource to the user *the
first time* because there is a no-cache directive associated with it.
IMO there is noting in the HTTP spec that even hints that this is how
the no-cache directive is to be used. If IE needs to temporarily sto
Darryl L. Miles wrote:
Mark Leone wrote:
It's a silly problem. I ran in to it a while back, and it really
mystified me until I found the bug write-up. Tomcat is doing the
right thing, but MS has declared that IE is working "as designed" in
this. FWIW, the HTTP spec is clear that the no-cach
Mark Leone wrote:
It's a silly problem. I ran in to it a while back, and it really
mystified me until I found the bug write-up. Tomcat is doing the right
thing, but MS has declared that IE is working "as designed" in this.
FWIW, the HTTP spec is clear that the no-cache behavior applies to
HT
If users are having this problem only when the server is serving content
from a protected context in Tomcat, then it is highly likely that you
have run into this.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27122
It's something in IE that most people would call a bug, but MS has
chosen
Thanks a lotI am using SSL and this is definitely a good direction
to work on
On 6/6/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> You are using SSL ?
>
> try:
>
> BrowserMatch ".*MSIE.*" nokeepalive ssl-unclean-shutdown
>
> regards
>
>
> Quoting Joe Plautz <[EMAIL PROTECTED]>:
>
Rafał Krupiński wrote:
Joe Plautz wrote:
Simple, test with IE as well.
yet simpler, tell your users it's IE problem and to use firefox
instead :)
It is still worth investigating. Mozilla/Firefox is eager to correct
badly formed HTML, just as IE is. I would advise you to install Tidy
H
Hi,
IMHO the best solution is to run tcpdump (or ethereel) on the server,
and log the IE users
traffic (and try to limit it to only 1 user as you seem to indicate that
you can easily reproduce
the problem). That will show you exactly what is going on. Anything else
is just speculation.
Regar
You are using SSL ?
try:
BrowserMatch ".*MSIE.*" nokeepalive ssl-unclean-shutdown
regards
Quoting Joe Plautz <[EMAIL PROTECTED]>:
> If it was only that simple.
>
> Rafał Krupiński wrote:
> > Joe Plautz wrote:
> >
> >> Simple, test with IE as well.
> >
> >
> > yet simpler, tell your users
sudip shrestha wrote:
Dude: Read the email first...
I am informing of the problem after we experienced with IE...
As you have said, YOU did not expirience it, since you're using FireFox.
It would be most advisable to do two things:
1. Use IE yourself (I know, I loathe it, too, and prefe
Please see my previous post in this thread for some actual help
(potentially anyway).
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Mon, June 6, 2005 11:14 am, sudip shrestha said:
> I have no idea why you are continuing on this path
I have no idea why you are continuing on this pathBut all I am
looking for is suggestions on how to debug this problem with IE, if
there is any. I am not offerring any excuse!! It's my work related
work. I have had few issues with IE in the past such as url
redirection problem but I have man
If it was only that simple.
Rafał Krupiński wrote:
Joe Plautz wrote:
Simple, test with IE as well.
yet simpler, tell your users it's IE problem and to use firefox instead :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Sorry for not including the smiley face but, dude, you're informing of a
problem that exists within a browser that is used by the vast majority
of web users and for some reason refused to test with it. "Works on my
box" is not a valid excuse.
Here's a link to a html validator, http://validator
Joe Plautz wrote:
Simple, test with IE as well.
yet simpler, tell your users it's IE problem and to use firefox instead :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Moving on to a more helpful answer...
Have you tried using something like HTTPWatch to see what's going on? IE
seems to display that page generically for a host of different problems,
and viewing the underlying HTTP transaction might narrow things down a
bit.
Also, you could ask your users to tu
Dude: Read the email first...
I am informing of the problem after we experienced with IE...
On 6/6/05, Joe Plautz <[EMAIL PROTECTED]> wrote:
> Simple, test with IE as well.
>
> sudip shrestha wrote:
> > I have a struts-hibernate powered webapp running off a debian box, jdk
> > 1.5 and tomcat 5.5
Simple, test with IE as well.
sudip shrestha wrote:
I have a struts-hibernate powered webapp running off a debian box, jdk
1.5 and tomcat 5.5.7
I have IE users complaining about page not found problems from time to
time where as Firefox users never. I myselft have never encountered
this prob
I have a struts-hibernate powered webapp running off a debian box, jdk
1.5 and tomcat 5.5.7
I have IE users complaining about page not found problems from time to
time where as Firefox users never. I myselft have never encountered
this problem as I use FirefoxThis led me to thinking that th
23 matches
Mail list logo
