Re: IE-Page not found problem
> 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. It will happen > when IE uses SSL to download *any* > file that is not being rendered in >the browser, when the no-cache > directive is included in the response. Absolutely. Worth having this clearly stated for the archives for sure. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] [Message truncated. Tap Edit->Mark for Download to get remaining portion.] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
> 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. It will happen > when IE uses SSL to download *any* > file that is not being rendered in >the browser, when the no-cache > directive is included in the response. Absolutely. Worth having this clearly stated for the archives for sure. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] [Message truncated. Tap Edit->Mark for Download to get remaining portion.] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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 wound up writing a filter that lets me define paths that WILL NOT have the cache headers set, all others they are set for (because all but three paths in my app needed the headers set, the 3 were where PDFs get generated). I use this in place of the Struts setting. This filter will appear in my Sourceforge JavaWebParts project, in case anyone else might be interested. Keep in mind, this is not just a problem with pdf files. It will happen when IE uses SSL to download *any* file that is not being rendered in the browser, when the no-cache directive is included in the response. -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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 two weeks ago when I ran into this very problem, but it turned out to be caused by this Struts option as I was running under Websphere. The point being that even if you can disable the option in Tomcat (and I'm not sure you can?), if you are using Struts you still could experience the same issue if you aren't aware the the headers could be set in two places. FYI, I wound up writing a filter that lets me define paths that WILL NOT have the cache headers set, all others they are set for (because all but three paths in my app needed the headers set, the 3 were where PDFs get generated). I use this in place of the Struts setting. This filter will appear in my Sourceforge JavaWebParts project, in case anyone else might be interested. Frank Mark Leone wrote: 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 the orginary request) store it to disk (if the implementation needs to). That's a charitable way to look at it, and an interesting observation. However, MS explicitly justifies the behavior in reference to the "no-cache" directive (see second link below), and I believe that neither the HTTP 1.0 Pragma semantics nor the HTTP 1.1 Pragma and Cache-Control semantics support the behavior. Given, as you pointed out, that the "no-store" option in HTTP 1.1 clears it up, then I think IE's implementation is even more unreasonable, as there is a check-box for HTTP 1.1 support. I've worked with dynamic HTML for quite a few years and can't remember stumbling over this problem, what is the simplest server response that triggers this problem in IE ? The problem occurs when using IE over an SSL connection, when the server includes either "cache-control: no-cache" or "pragma: no-cache" headers, or both, in the response, and the user is attempting to download a file that is not rendered in the browser (e.g., the file is either to be saved to disk or launched in some app other than a browser). Note that IE does not manifest the problem when the no-cache directives are sent in the response for non-SSL connections. I believe that Tomcat sends the no-cache directives when serving a resource from a protected context, i.e. one for which a is defined. (Mary-Beth reported here earlier that she got IE to behave properly by unchecking the option "Do not save encrypted pages to disk," but I tried this and it did not alleviate the problem. I believe Mary-Beth was dealing with a different issue. It's worth noting that MS does not list unchecking this option as a workaround in their bug report response for this issue.) The Tomcat bug report on it can be found here: http://issues.apache.org/bugzilla/show_bug.cgi?id=27122 And the IE bug report and MS response can be found here: http://support.microsoft.com/?id=316431 The issue is especially vexing IMO because of how it manifests. IE actually draws the download box with the progress bar, showing the correct web address and even the correct mime type of the resource. Then instead of beginning the download it suddenly throws up a window that says the site is unreachable. -Mark Darryl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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 the orginary request) store it to disk (if the implementation needs to). That's a charitable way to look at it, and an interesting observation. However, MS explicitly justifies the behavior in reference to the "no-cache" directive (see second link below), and I believe that neither the HTTP 1.0 Pragma semantics nor the HTTP 1.1 Pragma and Cache-Control semantics support the behavior. Given, as you pointed out, that the "no-store" option in HTTP 1.1 clears it up, then I think IE's implementation is even more unreasonable, as there is a check-box for HTTP 1.1 support. I've worked with dynamic HTML for quite a few years and can't remember stumbling over this problem, what is the simplest server response that triggers this problem in IE ? The problem occurs when using IE over an SSL connection, when the server includes either "cache-control: no-cache" or "pragma: no-cache" headers, or both, in the response, and the user is attempting to download a file that is not rendered in the browser (e.g., the file is either to be saved to disk or launched in some app other than a browser). Note that IE does not manifest the problem when the no-cache directives are sent in the response for non-SSL connections. I believe that Tomcat sends the no-cache directives when serving a resource from a protected context, i.e. one for which a is defined. (Mary-Beth reported here earlier that she got IE to behave properly by unchecking the option "Do not save encrypted pages to disk," but I tried this and it did not alleviate the problem. I believe Mary-Beth was dealing with a different issue. It's worth noting that MS does not list unchecking this option as a workaround in their bug report response for this issue.) The Tomcat bug report on it can be found here: http://issues.apache.org/bugzilla/show_bug.cgi?id=27122 And the IE bug report and MS response can be found here: http://support.microsoft.com/?id=316431 The issue is especially vexing IMO because of how it manifests. IE actually draws the download box with the progress bar, showing the correct web address and even the correct mime type of the resource. Then instead of beginning the download it suddenly throws up a window that says the site is unreachable. -Mark Darryl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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 store the resource in order to provide it to the user, and a no-cache header is present, then it should find a way to give it to the user without caching it (which of course is not the same thing as temporarily storing it for spooling purposes), instead of refusing to let the user see it the first time the server sends it, and then hiding behind the HTTP spec to justify a poor implementation. I think the end result speaks for itself. What possible use could a no-cache directive have if it means that user agents can't even give the resource to the user the first time it's requested? If this is really what the spec means, then every non-cacheable resource on the web is a self-licking ice-cream cone. Probably tastes great, but no one will ever really know. All the other user agent implementers seem to have interpreted the spec appropriately, without failing to give the users the resource the server explicitly provided to them. 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 the orginary request) store it to disk (if the implementation needs to). From the HTTP spec point of view caching is "just an observable concept", I make this statement to disconnect it from the presumption it has anything to do with storing to disk or not. I agree with you on what possible use could no-cache be within IE if implemented their way. I've worked with dynamic HTML for quite a few years and can't remember stumbling over this problem, what is the simplest server response that triggers this problem in IE ? Darryl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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-cache behavior applies to HTTP intermediaries, not user agents. "the HTTP spec is clear that the no-cache behavior applies to HTTP intermediaries, not user agents." Are you really sure ? I have always understood the HTTP 1.1, "Cache-Control no-cache" response header to be able to control both intermediaries and user agent caching activities. The specification does not talk in terms of user agent caches and intermediary caches it only talks in terms of caching operations (for the large part) with a few additional directives to target shared-public and/or private cache behaviour. Yes, my comment was imprecise. I should have said that the HTTP spec is clear that the no-cache behavior does not apply to user agents in the way that it is implemented in IE. Having said that, reference your two statements about re-use: As there is no differenciation between shared-public and private caches when it comes to the "no-cache" directive, all caches must revalidate the request before subsequent reuse... The important point of "no-cache" is your HTTP client must ask the server before you re-use your cached object, its upto the server to then say "No! Here use this instead". This is precisely the issue with IE. The failure to make the resource available to the user does not occur on a request for re-use. I agree that the spec can be read to indicate that a no-cache directive should mean that the user agent serves the resource once and then requests re-validation from the origin server for any subsequent requests for the same resource. But that's not what causes the subject error condition. The user requests a resource, and IE says essentially the following: "Because of the way I've been implemented, I have to store this resource temporarily in order to show it to the user. Now that means I have to cache it... Oh, I just noticed, this resource has a no-cache directive in the header. I can't store this in cache... [forgetting the actions just taken] Hey, where's that resource I just copied into cache? I don't see it. The web site must be unreachable. That's what I'll tell the user." 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 store the resource in order to provide it to the user, and a no-cache header is present, then it should find a way to give it to the user without caching it (which of course is not the same thing as temporarily storing it for spooling purposes), instead of refusing to let the user see it the first time the server sends it, and then hiding behind the HTTP spec to justify a poor implementation. I think the end result speaks for itself. What possible use could a no-cache directive have if it means that user agents can't even give the resource to the user the first time it's requested? If this is really what the spec means, then every non-cacheable resource on the web is a self-licking ice-cream cone. Probably tastes great, but no one will ever really know. All the other user agent implementers seem to have interpreted the spec appropriately, without failing to give the users the resource the server explicitly provided to them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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 HTTP intermediaries, not user agents. "the HTTP spec is clear that the no-cache behavior applies to HTTP intermediaries, not user agents." Are you really sure ? I have always understood the HTTP 1.1, "Cache-Control no-cache" response header to be able to control both intermediaries and user agent caching activities. The specification does not talk in terms of user agent caches and intermediary caches it only talks in terms of caching operations (for the large part) with a few additional directives to target shared-public and/or private cache behaviour. As there is no differenciation between shared-public and private caches when it comes to the "no-cache" directive, all caches must revalidate the request before subsequent reuse, this means an If-Modified-Since is an allowed type of request to the server, but since most non-static Tomcat/Perl/CGI/WhateverTechnology do not handle If-Modified-Since request directives anyway. A new page is generated and a 200 response given, the net effect is no observable caching effect. The important point of "no-cache" is your HTTP client must ask the server before you re-use your cached object, its upto the server to then say "No! Here use this instead". This does not help you with your IE problem thats just bad handling of the response. Darryl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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 to call a feature. The problem occurs when Tomcat appends cache control headers (i.e. "cache-control:no-cache" and "pragma:no-cache") that indicate no caching is allowed by HTTP intermediaries. However, IE interprets these headers to mean that temporary storage in the client is also forbidden. So IE attempts to write the file to temporary storage as it does for all file downloads, and cancels the operation when it encounters the cache control headers. Then the app or file system (depending on whether you're running or saving the file) tries to find the file, doesn't find it, and cleverly reports that the site is unreachable. To fix it, you simply have to configure Tomcat to not set the cache control headers when serving content from a protected context. Create a valve as follows, and put it in the appropriate element. Make sure to substitute the class for whatever type of authentication you're using. 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 HTTP intermediaries, not user agents. -Mark 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 problem as I use FirefoxThis led me to thinking that this might be a IE problem...Any suggestions on how to move ahead on the problem? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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]>: > > > 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 additional commands, e-mail: [EMAIL PROTECTED] > > > > > > . > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > /\ > /\/ \/\ > Powerd by llbc.de - letz board it, yeahhh !!/ \ \ \ \ > --- / / \ \ > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: IE-Page not found problem
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 HTML Validator in your Firefox and to weed out all errors and warnings, if possible. Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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. Regards Andrew sudip shrestha wrote: 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 managed to find the fix for those. So, I was thinking maybe somebody in the users list have had some kind of positive experience with this in the past. Frank's suggestion on this regard was constructive. I work in a huge company...suddenly asking users to change the browser is not exactly the pratical solution either. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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 it's IE problem and to use firefox instead :) > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > . > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- /\ /\/ \/\ Powerd by llbc.de - letz board it, yeahhh !!/ \ \ \ \ --- / / \ \ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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 prefer Mozilla+Tidy_HTML_Validator) 2. Look at the logs - pages that were missed should show up in the logs. Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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 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 managed to find the fix for those. So, > I was thinking maybe somebody in the users list have had some kind of > positive experience with this in the past. Frank's suggestion on this > regard was constructive. I work in a huge company...suddenly asking > users to change the browser is not exactly the pratical solution > either. > > On 6/6/05, Joe Plautz <[EMAIL PROTECTED]> wrote: >> 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.w3.org/ >> >> Here's a link that explains a lot of the known issues, >> http://www.howtocreate.co.uk/wrongWithIE/ >> >> sudip shrestha wrote: >> > 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.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 this >> >>>might be a IE problem...Any suggestions on how to move ahead on the >> >>>problem? >> >>> >> >>>- >> >>>To unsubscribe, e-mail: [EMAIL PROTECTED] >> >>>For additional commands, e-mail: [EMAIL PROTECTED] >> >>> >> >>>. >> >>> >> >> >> >>- >> >>To unsubscribe, e-mail: [EMAIL PROTECTED] >> >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > . >> > >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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 managed to find the fix for those. So, I was thinking maybe somebody in the users list have had some kind of positive experience with this in the past. Frank's suggestion on this regard was constructive. I work in a huge company...suddenly asking users to change the browser is not exactly the pratical solution either. On 6/6/05, Joe Plautz <[EMAIL PROTECTED]> wrote: > 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.w3.org/ > > Here's a link that explains a lot of the known issues, > http://www.howtocreate.co.uk/wrongWithIE/ > > sudip shrestha wrote: > > 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.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 this > >>>might be a IE problem...Any suggestions on how to move ahead on the > >>>problem? > >>> > >>>- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>>. > >>> > >> > >>- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > . > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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 additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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.w3.org/ Here's a link that explains a lot of the known issues, http://www.howtocreate.co.uk/wrongWithIE/ sudip shrestha wrote: 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.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 this might be a IE problem...Any suggestions on how to move ahead on the problem? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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]
Re: IE-Page not found problem
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 turn off the "friendly messages" option... I'm not certain, but I believe they will get you slightly more helpful (to you) messages with that option turned off. It's under Tools...Internet Options... Advanced... Show Friendly HTTP Error Messages. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, June 6, 2005 10:22 am, Joe Plautz said: > 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 problem as I use FirefoxThis led me to thinking that this >> might be a IE problem...Any suggestions on how to move ahead on the >> problem? >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> . >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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.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 this > > might be a IE problem...Any suggestions on how to move ahead on the > > problem? > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > . > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE-Page not found problem
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 problem as I use FirefoxThis led me to thinking that this might be a IE problem...Any suggestions on how to move ahead on the problem? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IE-Page not found problem
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 this might be a IE problem...Any suggestions on how to move ahead on the problem? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
