Re: Did the default HTTP expires header change in Tomcat?

2002-02-15 Thread Jonathan Eric Miller

I found that it does the following at lines 484-486 in
AuthenticatorBase.java.

sresponse.setHeader("Pragma", "No-cache");
sresponse.setHeader("Cache-Control", "no-cache");
sresponse.setDateHeader("Expires", 1);

I also found that the servlet API seems to provide no way to delete these
headers (short of deleting all the headers by calling reset()) or query to
see what headers are set in the HttpServletResponse object.

Note, doing a setHeader() with the value set to null or "" doesn't delete
the header. If I set them all to null or "", Netscape 4 still doesn't cache
the page like it does when they're not present.

Any ideas?

Also, why is "Expires" being set? I'm assuming "Pragma" is needed for HTTP
1.0 backward compatibility. "Expires" shouldn't be necessary, should it?

IMHO, it should be possible to turn caching back on if you want it on. For
my application, I'm using SSL because I don't want the authentication
information getting sniffed, the rest of the network traffic I don't care
about much and I don't care if it gets cached. It seems like a Cache-Control
setting of "no-store" would work better (as far as I know, this means it's
OK to cache the pages in volatile memory, just not nonvolatile memory).

Jon

- Original Message -
From: "Jonathan Eric Miller" <[EMAIL PROTECTED]>
To: "Remy Maucherat" <[EMAIL PROTECTED]>; "Tomcat Users List"
<[EMAIL PROTECTED]>
Sent: Friday, February 15, 2002 11:35 AM
Subject: Re: Did the default HTTP expires header change in Tomcat?


> Thanks. Is there a way that I can override this behavior and revert back
to
> the old behavior? I'm guessing that you're using a HTTP header to do this?
> I'm guessing that I can use HttpServletResponse.setHeader() to override
it?
> Is it the "expires" header, or something else? What value is it setting
now,
> and what was the original value?
>
> Jon
>
> - Original Message -
> From: "Remy Maucherat" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>; "Jonathan Eric
> Miller" <[EMAIL PROTECTED]>
> Sent: Thursday, February 14, 2002 6:26 PM
> Subject: Re: Did the default HTTP expires header change in Tomcat?
>
>
> > > Yeah, I just tried my application in 4.0.1 and it doesn't expire.
> > Something
> > > seems to have changed in 4.0.2.
> >
> > Yes, the content which is protected through a security constraint is
> marked
> > as non cacheable (which fixes a security problem where a proxy would
cache
> > the pages).
> >
> > Remy
> >
>
>
> --
> To unsubscribe:   <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>




Re: Did the default HTTP expires header change in Tomcat?

2002-02-15 Thread Jonathan Eric Miller

Thanks. Is there a way that I can override this behavior and revert back to
the old behavior? I'm guessing that you're using a HTTP header to do this?
I'm guessing that I can use HttpServletResponse.setHeader() to override it?
Is it the "expires" header, or something else? What value is it setting now,
and what was the original value?

Jon

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>; "Jonathan Eric
Miller" <[EMAIL PROTECTED]>
Sent: Thursday, February 14, 2002 6:26 PM
Subject: Re: Did the default HTTP expires header change in Tomcat?


> > Yeah, I just tried my application in 4.0.1 and it doesn't expire.
> Something
> > seems to have changed in 4.0.2.
>
> Yes, the content which is protected through a security constraint is
marked
> as non cacheable (which fixes a security problem where a proxy would cache
> the pages).
>
> Remy
>


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>




Re: Did the default HTTP expires header change in Tomcat?

2002-02-14 Thread Remy Maucherat

> Yeah, I just tried my application in 4.0.1 and it doesn't expire.
Something
> seems to have changed in 4.0.2.

Yes, the content which is protected through a security constraint is marked
as non cacheable (which fixes a security problem where a proxy would cache
the pages).

Remy


--
To unsubscribe:   
For additional commands: 
Troubles with the list: 




Re: Did the default HTTP expires header change in Tomcat?

2002-02-14 Thread Jonathan Eric Miller

Yeah, I just tried my application in 4.0.1 and it doesn't expire. Something
seems to have changed in 4.0.2.

Jon

- Original Message -
From: "Jonathan Eric Miller" <[EMAIL PROTECTED]>
To: "Tomcat User List" <[EMAIL PROTECTED]>
Sent: Thursday, February 14, 2002 6:14 PM
Subject: Did the default HTTP expires header change in Tomcat?


> In the applications that I'm developing, I used to be able to click on the
> Web browser back button to return to a page that contained form data that
> was generated by a HTTP post. I noticed that it now gives me an error
> message like "Page has Expired" when I try to do it. It does this in both
IE
> and Netscape. It never used to do this. Did the behavior in Tomcat change?
>
> If so, what do I need to do to return to the previous behavior? Set an
HTTP
> header like "expires" or something?
>
> I noticed the following in the release notes in the fixed bugs section.
> Could this have something to do with it?
>
> 6151  Manager servlet behaves bad in IE without an "Expires: -1" http
header
>
> Jon
>
>


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>




Did the default HTTP expires header change in Tomcat?

2002-02-14 Thread Jonathan Eric Miller

In the applications that I'm developing, I used to be able to click on the
Web browser back button to return to a page that contained form data that
was generated by a HTTP post. I noticed that it now gives me an error
message like "Page has Expired" when I try to do it. It does this in both IE
and Netscape. It never used to do this. Did the behavior in Tomcat change?

If so, what do I need to do to return to the previous behavior? Set an HTTP
header like "expires" or something?

I noticed the following in the release notes in the fixed bugs section.
Could this have something to do with it?

6151  Manager servlet behaves bad in IE without an "Expires: -1" http header

Jon



--
To unsubscribe:   
For additional commands: 
Troubles with the list: