You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Dave Johnson <sn...@gmail.com> on 2006/08/31 18:50:32 UTC
Ready for a 3.0 RC? What about themes/plugins?
The docs are up-to-date and bugs are under control.
Here's an issue I'd like to resolve (and document in the Installation
Guide) before the RC:
We recently decided to ship only a couple of themes and plugins and we
still need to figure out what to do with the themes and plugins that
we don't ship with Roller.
I'd like to propose that, not only should we remove them from the
release, we should also remove them from Apache SVN. We should remove
them from SVN and move them to the old Roller project at Java.Net and
make them available for download there. Here's why:
- We've already re-purposed the old Roller project site as the "Roller
Support" site -- to host LGPL components and plugins/themes that
depend on LGPL.
- The extra themes and plugins aren't essential to the community of
developers maintaining Roller. Ideally, Roller should ship with a
couple really good themes/plugins and the rest should be provided an
maintained by the community of Roller users.
- By using the "Struts Applications" model, we can encourage more
theme development by the community. Struts team members established a
Sourceforge project to host Struts add-ons and contributors who don't
necessarily have Apache committer status.
- Themes and plugins can use other-licensed components freely, since
the Roller Support project is not Apache territory.
- Dave
Re: Ready for a 3.0 RC? What about themes/plugins?
Posted by Allen Gilliland <al...@sun.com>.
definite +1
I have been in a lot of meetings so far this week so I haven't had much
time, but I plan to spend some time this afternoon doing the plugins
move that i suggested and finishing up the few remaining items on my 3.0
TODO list.
-- Allen
Dave Johnson wrote:
> The docs are up-to-date and bugs are under control.
>
> Here's an issue I'd like to resolve (and document in the Installation
> Guide) before the RC:
>
> We recently decided to ship only a couple of themes and plugins and we
> still need to figure out what to do with the themes and plugins that
> we don't ship with Roller.
>
> I'd like to propose that, not only should we remove them from the
> release, we should also remove them from Apache SVN. We should remove
> them from SVN and move them to the old Roller project at Java.Net and
> make them available for download there. Here's why:
>
> - We've already re-purposed the old Roller project site as the "Roller
> Support" site -- to host LGPL components and plugins/themes that
> depend on LGPL.
>
> - The extra themes and plugins aren't essential to the community of
> developers maintaining Roller. Ideally, Roller should ship with a
> couple really good themes/plugins and the rest should be provided an
> maintained by the community of Roller users.
>
> - By using the "Struts Applications" model, we can encourage more
> theme development by the community. Struts team members established a
> Sourceforge project to host Struts add-ons and contributors who don't
> necessarily have Apache committer status.
>
> - Themes and plugins can use other-licensed components freely, since
> the Roller Support project is not Apache territory.
>
>
> - Dave
Re: Ready for a 3.0 RC? What about themes/plugins?
Posted by Matt Raible <mr...@gmail.com>.
On the "rel" front - I noticed that rel="nofollow" is added to all
links. However, if "rel" is already on the link, it's gets added
twice. For example, I add rel="lightbox" for image popups.
Matt
On 8/31/06, Sean Gilligan <se...@msgilligan.com> wrote:
> Hi Dave, et. al.
>
> Sorry for reverting to lurker mode for the past few months. :(
>
> I recently installed the 3.0 branch on my MacBook Pro and it looks
> really nice. I was wondering what the schedule was going to be. I'm
> ready to do some more testing.
>
> I also want to propose an additional 3.0 feature if it is not too late:
> A rel="enclosure" plugin for podcasting and videoblogging.
>
> If I write a proposal and the committers review and approve, I believe I
> could have a patch by Aug 15th. (I have a web page that discusses the
> issue and provides links to specs and other implementations here:
> http://www.msgilligan.com/rss-enclosure-bp.html)
>
> Do you think this could make it into 3.0?
>
> Thanks,
>
> Sean
>
>
> Dave Johnson wrote:
> > The docs are up-to-date and bugs are under control.
> >
> > Here's an issue I'd like to resolve (and document in the Installation
> > Guide) before the RC:
> >
> > We recently decided to ship only a couple of themes and plugins and we
> > still need to figure out what to do with the themes and plugins that
> > we don't ship with Roller.
> >
> > I'd like to propose that, not only should we remove them from the
> > release, we should also remove them from Apache SVN. We should remove
> > them from SVN and move them to the old Roller project at Java.Net and
> > make them available for download there. Here's why:
> >
> > - We've already re-purposed the old Roller project site as the "Roller
> > Support" site -- to host LGPL components and plugins/themes that
> > depend on LGPL.
> >
> > - The extra themes and plugins aren't essential to the community of
> > developers maintaining Roller. Ideally, Roller should ship with a
> > couple really good themes/plugins and the rest should be provided an
> > maintained by the community of Roller users.
> >
> > - By using the "Struts Applications" model, we can encourage more
> > theme development by the community. Struts team members established a
> > Sourceforge project to host Struts add-ons and contributors who don't
> > necessarily have Apache committer status.
> >
> > - Themes and plugins can use other-licensed components freely, since
> > the Roller Support project is not Apache territory.
> >
> >
> > - Dave
> >
> >
>
>
Re: Ready for a 3.0 RC? What about themes/plugins?
Posted by Allen Gilliland <al...@sun.com>.
Sean Gilligan wrote:
> Allen Gilliland wrote:
>> i agree, we aren't going to add new features for 3.0.
>
> I don't want to hold up 3.0 -- it has most of the features in my
> wishlist implemented! :) The 3.1 release is a good target (although I
> may merge it in sooner in my build)
>
>>
>> it looked like you were just suggesting a plugin and if that's the
>> case then that wouldn't go into the src tree anyways.
>
> Most likely, it *shouldn't* be a plugin, for three reasons:
>
> 1) Podcasting and videoblogging are important enough that they should be
> supported in the core. (e.g. the current Podcast capability)
> 2) I don't think there are any real drawbacks to having this enabled (by
> default or all-the-time)
> 3) I'm not sure there is a plug-in mechanism in Roller that will support
> it. (More on this later)
>
>
> you should just develop
>> it and then add it to your running installation yourself.
>
> Although it is (last I checked, which was many months ago) an MT plugin,
> I believe it is built-in to WordPress and I really think it should be an
> out-of-box feature of any Blog SW that wants to support
> Podcasting/Vlogging.
Cool. Now would be the time to start working on proposals for 3.1 then.
I know I am planning to get my 3.1 proposals at least started by next
week, and if I'm lucky I'll have them done by the end of the week.
-- Allen
>
> -- Sean
Re: Ready for a 3.0 RC? What about themes/plugins?
Posted by Sean Gilligan <se...@msgilligan.com>.
Allen Gilliland wrote:
> i agree, we aren't going to add new features for 3.0.
I don't want to hold up 3.0 -- it has most of the features in my
wishlist implemented! :) The 3.1 release is a good target (although I
may merge it in sooner in my build)
>
> it looked like you were just suggesting a plugin and if that's the case
> then that wouldn't go into the src tree anyways.
Most likely, it *shouldn't* be a plugin, for three reasons:
1) Podcasting and videoblogging are important enough that they should be
supported in the core. (e.g. the current Podcast capability)
2) I don't think there are any real drawbacks to having this enabled (by
default or all-the-time)
3) I'm not sure there is a plug-in mechanism in Roller that will support
it. (More on this later)
you should just develop
> it and then add it to your running installation yourself.
Although it is (last I checked, which was many months ago) an MT plugin,
I believe it is built-in to WordPress and I really think it should be an
out-of-box feature of any Blog SW that wants to support Podcasting/Vlogging.
-- Sean
Re: Ready for a 3.0 RC? What about themes/plugins?
Posted by Allen Gilliland <al...@sun.com>.
Dave Johnson wrote:
> On 8/31/06, Sean Gilligan <se...@msgilligan.com> wrote:
>> Sean Gilligan wrote:
>> > If I write a proposal and the committers review and approve, I
>> believe I
>> > could have a patch by Aug 15th.
>> Sorry, I meant SEPTEMBER 15th.
>
> We're trying to get an RC out this week, so I'd vote -1 on that just
> based on timing.
i agree, we aren't going to add new features for 3.0.
it looked like you were just suggesting a plugin and if that's the case
then that wouldn't go into the src tree anyways. you should just develop
it and then add it to your running installation yourself. Roller is no
longer going to be putting plugins into the core source tree.
-- Allen
>
> However, I'd like to rally folks for a quick follow-on 3.1 release a
> month after 3.0 to address bugs and minor improvements.
>
> - Dave
Re: Ready for a 3.0 RC? What about themes/plugins?
Posted by Sean Gilligan <se...@msgilligan.com>.
Dave Johnson wrote:
> On 8/31/06, Sean Gilligan <se...@msgilligan.com> wrote:
>> Sean Gilligan wrote:
>> > If I write a proposal and the committers review and approve, I
>> believe I
>> > could have a patch by Aug 15th.
>> Sorry, I meant SEPTEMBER 15th.
>
> We're trying to get an RC out this week, so I'd vote -1 on that just
> based on timing.
Fair enough.
>
> However, I'd like to rally folks for a quick follow-on 3.1 release a
> month after 3.0 to address bugs and minor improvements.
Sounds good.
-- Sean
Re: problems with 3.0 on IE
Posted by Anil Gangolli <an...@busybuddha.org>.
I'm basing this on my reading of the Expires header description in the HTTP
1.1 spec 14.21: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html and
13.2.1: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2 and
my experiments with Firefox and IE.
We could also include the HTTP 1.1 header "Cache-Control: must-revalidate".
We can do further research as well. In any case, I've now localized that
logic. If we want to change it or remove it; it is in one place.
--a.
----- Original Message -----
From: "Allen Gilliland" <al...@sun.com>
To: <ro...@incubator.apache.org>
Sent: Tuesday, September 05, 2006 9:33 PM
Subject: Re: problems with 3.0 on IE
>
>
> Anil Gangolli wrote:
>>
>> Adding an "Expires" header in the past solves this. The browser will
>> revalidate its cache. Both IE and Firefox send the If-Modified-Since
>> header and either get the Not Modified response or hit the server-side
>> cache.
>
> I have never really used the Expires header, but are we sure that's the
> right approach? It sounds like that is somewhat falsely indicating that
> the content has Expired, so I would think that its possible that some
> browsers might consider that an indication that it doesn't need to bother
> with doing the If-Modified-Since check.
>
>>
>> I plan to commit changes that set the Expires header in each place that
>> we currently set the Last-Modified header. There are calls in about 8
>> places. I think we need to localize this better.
>>
>> There is other minor messiness to clean up here too. The millisecond
>> truncation issue is handled in two different ways. In one place
>> (PlanetFeedServlet) the code adds 1000 to the millisecond value before
>> setting the header, effectively rounding up while setting the header. In
>> most other places it truncates down before comparing; but, it is only
>> using this logic for the site-wide case. It should use it for individual
>> blogs as well.
>
> I'm not sure why the millisecond precision error is handled differently in
> the PlanetFeedServlet case, but the reason we don't make that adjustment
> for individual blogs is because it's not needed. Because the lastModified
> date for weblogs comes directly from the db I found that the precision
> that I got on the Date which was loaded from the db was already truncated.
>
> So it seems that only the original Date object initialized by the jvm is
> capable of that extra precision, and if the Date is ever saved/loaded from
> the db or set/get from the http headers then the truncation happens. So
> that's why we aren't adjusting the precision of the Date for individual
> weblogs.
>
> -- Allen
>
>>
>> I'll hope to do some cleanup in a separate checkin later.
>>
>> --a.
>>
>>
>>
>> ----- Original Message ----- From: "Anil Gangolli" <an...@busybuddha.org>
>> To: <ro...@incubator.apache.org>
>> Sent: Tuesday, September 05, 2006 8:02 AM
>> Subject: Re: problems with 3.0 on IE
>>
>>
>>> I am going to try sending a combination of Expires and Last-Modified and
>>> see if this can induce IE both to send subsequent requests and to
>>> include the If-Modified-Since header. (Will test with Firefox as well).
>>> Based on my reading of the spec, this should work.
>>>
>>
>
Re: problems with 3.0 on IE
Posted by Allen Gilliland <al...@sun.com>.
Anil Gangolli wrote:
>
> Adding an "Expires" header in the past solves this. The browser will
> revalidate its cache. Both IE and Firefox send the If-Modified-Since
> header and either get the Not Modified response or hit the server-side
> cache.
I have never really used the Expires header, but are we sure that's the
right approach? It sounds like that is somewhat falsely indicating that
the content has Expired, so I would think that its possible that some
browsers might consider that an indication that it doesn't need to
bother with doing the If-Modified-Since check.
>
> I plan to commit changes that set the Expires header in each place that
> we currently set the Last-Modified header. There are calls in about 8
> places. I think we need to localize this better.
>
> There is other minor messiness to clean up here too. The millisecond
> truncation issue is handled in two different ways. In one place
> (PlanetFeedServlet) the code adds 1000 to the millisecond value before
> setting the header, effectively rounding up while setting the header.
> In most other places it truncates down before comparing; but, it is only
> using this logic for the site-wide case. It should use it for
> individual blogs as well.
I'm not sure why the millisecond precision error is handled differently
in the PlanetFeedServlet case, but the reason we don't make that
adjustment for individual blogs is because it's not needed. Because the
lastModified date for weblogs comes directly from the db I found that
the precision that I got on the Date which was loaded from the db was
already truncated.
So it seems that only the original Date object initialized by the jvm is
capable of that extra precision, and if the Date is ever saved/loaded
from the db or set/get from the http headers then the truncation
happens. So that's why we aren't adjusting the precision of the Date
for individual weblogs.
-- Allen
>
> I'll hope to do some cleanup in a separate checkin later.
>
> --a.
>
>
>
> ----- Original Message ----- From: "Anil Gangolli" <an...@busybuddha.org>
> To: <ro...@incubator.apache.org>
> Sent: Tuesday, September 05, 2006 8:02 AM
> Subject: Re: problems with 3.0 on IE
>
>
>> I am going to try sending a combination of Expires and Last-Modified
>> and see if this can induce IE both to send subsequent requests and to
>> include the If-Modified-Since header. (Will test with Firefox as
>> well). Based on my reading of the spec, this should work.
>>
>
Re: problems with 3.0 on IE
Posted by Anil Gangolli <an...@busybuddha.org>.
Adding an "Expires" header in the past solves this. The browser will
revalidate its cache. Both IE and Firefox send the If-Modified-Since header
and either get the Not Modified response or hit the server-side cache.
I plan to commit changes that set the Expires header in each place that we
currently set the Last-Modified header. There are calls in about 8 places.
I think we need to localize this better.
There is other minor messiness to clean up here too. The millisecond
truncation issue is handled in two different ways. In one place
(PlanetFeedServlet) the code adds 1000 to the millisecond value before
setting the header, effectively rounding up while setting the header. In
most other places it truncates down before comparing; but, it is only using
this logic for the site-wide case. It should use it for individual blogs as
well.
I'll hope to do some cleanup in a separate checkin later.
--a.
----- Original Message -----
From: "Anil Gangolli" <an...@busybuddha.org>
To: <ro...@incubator.apache.org>
Sent: Tuesday, September 05, 2006 8:02 AM
Subject: Re: problems with 3.0 on IE
>I am going to try sending a combination of Expires and Last-Modified and
>see if this can induce IE both to send subsequent requests and to include
>the If-Modified-Since header. (Will test with Firefox as well). Based on
>my reading of the spec, this should work.
>
Re: problems with 3.0 on IE
Posted by Anil Gangolli <an...@busybuddha.org>.
I am going to try sending a combination of Expires and Last-Modified and see
if this can induce IE both to send subsequent requests and to include the
If-Modified-Since header. (Will test with Firefox as well). Based on my
reading of the spec, this should work.
I'll also take a look at the aggregated front page case, assuming I can
figure out how to set that up. If this doesn't send Last-Modified headers,
I suspect it will work exactly like 2.3 in skirting the staleness issue.
In the cases I diagnosed to date, the problem was that IE with its checking
policy set to its default ("Automatically"), was not sending requests at
all.
In cases where we were not sending Last-Modified dates at all, IE under the
Automatic setting would revert to checking every time with no
If-Modified-Since header. This works as expected. It also explains why the
front page worked with IE in 2.3 but not in 3.0.
To get IE to work properly in the general case I had to set IE to "Check on
Every Visit" which causes it to make a request and send If-Modified-Since
headers when possible. This was also working as expected; I did not see any
of the millisecond granularity issues if there were any when I tested.
--a.
----- Original Message -----
From: "Allen Gilliland" <al...@sun.com>
To: <ro...@incubator.apache.org>
Sent: Monday, September 04, 2006 12:23 PM
Subject: Re: problems with 3.0 on IE
>
>
> Craig L Russell wrote:
>> Sorry if this is noisy, but if the http header handling of last modified
>> truncates the current date, we should know the truncation algorithm and
>> use it in the cached Date.
>>
>> We know the precision of Date: it's milliseconds. If the http headers
>> truncate to the nearest second, then Date will "always" (well, 999 times
>> out of a thousand ;-) be a mismatch.
>>
>> What if we always truncate Date to the same precision as http headers
>> use?
>
> yep, that's what I do ...
>
> lastModified = lastModified - (lastModified % 1000);
>
> I truncate the milliseconds from the lastModified long value before using
> it in the situations where this applies and I have tested and verified
> that this works properly on firefox.
>
> My message below was meant to tell Anil about this in case he wanted to
> verify that this isn't causing part of the problem with IE and the cache
> control http headers. I only tested this on firefox, so although it would
> be unlikely, it's possible that my solution isn't working properly for IE.
>
> -- Allen
>
>
>>
>> Craig
>>
>> On Sep 4, 2006, at 11:44 AM, Allen Gilliland wrote:
>>
>>> Normally this wouldn't be of any concern, but I noticed during
>>> development that when that cached Date object is actually set as the
>>> Last-Modified header it loses some precision, and so the actual long
>>> value you get from the Date.getTime() and the value you get from the
>>> If-Modified-Since header will almost always be non-equal due to the
>>> difference in precision. Namely, the long you get from the cached Date
>>> object will be some # of milliseconds ahead of the version you get from
>>> the If-Modified-Since header, which is truncated when it gets passed
>>> through the http headers. This basically means that the header will
>>> always be a matter milliseconds behind the cached Date and if you
>>> compare them directly then the header will always make it seem like the
>>> content has been modified.
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>
Re: problems with 3.0 on IE
Posted by Allen Gilliland <al...@sun.com>.
Craig L Russell wrote:
> Sorry if this is noisy, but if the http header handling of last modified
> truncates the current date, we should know the truncation algorithm and
> use it in the cached Date.
>
> We know the precision of Date: it's milliseconds. If the http headers
> truncate to the nearest second, then Date will "always" (well, 999 times
> out of a thousand ;-) be a mismatch.
>
> What if we always truncate Date to the same precision as http headers use?
yep, that's what I do ...
lastModified = lastModified - (lastModified % 1000);
I truncate the milliseconds from the lastModified long value before
using it in the situations where this applies and I have tested and
verified that this works properly on firefox.
My message below was meant to tell Anil about this in case he wanted to
verify that this isn't causing part of the problem with IE and the cache
control http headers. I only tested this on firefox, so although it
would be unlikely, it's possible that my solution isn't working properly
for IE.
-- Allen
>
> Craig
>
> On Sep 4, 2006, at 11:44 AM, Allen Gilliland wrote:
>
>> Normally this wouldn't be of any concern, but I noticed during
>> development that when that cached Date object is actually set as the
>> Last-Modified header it loses some precision, and so the actual long
>> value you get from the Date.getTime() and the value you get from the
>> If-Modified-Since header will almost always be non-equal due to the
>> difference in precision. Namely, the long you get from the cached
>> Date object will be some # of milliseconds ahead of the version you
>> get from the If-Modified-Since header, which is truncated when it gets
>> passed through the http headers. This basically means that the header
>> will always be a matter milliseconds behind the cached Date and if you
>> compare them directly then the header will always make it seem like
>> the content has been modified.
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: problems with 3.0 on IE
Posted by Craig L Russell <Cr...@Sun.COM>.
Sorry if this is noisy, but if the http header handling of last
modified truncates the current date, we should know the truncation
algorithm and use it in the cached Date.
We know the precision of Date: it's milliseconds. If the http headers
truncate to the nearest second, then Date will "always" (well, 999
times out of a thousand ;-) be a mismatch.
What if we always truncate Date to the same precision as http headers
use?
Craig
On Sep 4, 2006, at 11:44 AM, Allen Gilliland wrote:
> Normally this wouldn't be of any concern, but I noticed during
> development that when that cached Date object is actually set as
> the Last-Modified header it loses some precision, and so the actual
> long value you get from the Date.getTime() and the value you get
> from the If-Modified-Since header will almost always be non-equal
> due to the difference in precision. Namely, the long you get from
> the cached Date object will be some # of milliseconds ahead of the
> version you get from the If-Modified-Since header, which is
> truncated when it gets passed through the http headers. This
> basically means that the header will always be a matter
> milliseconds behind the cached Date and if you compare them
> directly then the header will always make it seem like the content
> has been modified.
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: problems with 3.0 on IE
Posted by Allen Gilliland <al...@sun.com>.
Thanks for looking into this Anil, it's definitely a bit unfortunate
that IE is causing this problem. I would imagine that lots of other
websites have this problem since it's not at all uncommon to have pages
that change frequently throughout the day.
One thing you can possibly look into is some debugging/comparison on the
Last-Modified and If-Modified-Since headers that are used on the
frontpage if it's set to aggregated mode. The dates for those headers
are managed differently than the ones for weblogs because when the
frontpage is in aggregated mode, meaning it is expected to show
site-wide data, then you can't rely on the weblog.lastModified attribute
to have the right date.
If you look in the PageServlet you'll see what I mean. For the
aggregated frontpage the lastModified date used for the cache control
headers is actually kept cached in memory in the SiteWideCache class.
Normally this wouldn't be of any concern, but I noticed during
development that when that cached Date object is actually set as the
Last-Modified header it loses some precision, and so the actual long
value you get from the Date.getTime() and the value you get from the
If-Modified-Since header will almost always be non-equal due to the
difference in precision. Namely, the long you get from the cached Date
object will be some # of milliseconds ahead of the version you get from
the If-Modified-Since header, which is truncated when it gets passed
through the http headers. This basically means that the header will
always be a matter milliseconds behind the cached Date and if you
compare them directly then the header will always make it seem like the
content has been modified.
To fix this I had to correct for that loss of precision so that the
cache control would actually work properly, you can see what's happening
in the PageServlet where I left a long comment about this. In any case,
I only checked this functionality on firefox during development, so it's
possible that IE works a bit differently and there is possibly still
some kind of problem when doing the cache control checking in IE. If
you set the PageServlet to DEBUG mode it should be pretty easy to check
this since the debug messaging shows both the lastModified and
ifModifiedSince dates that it is using for its comparison. So you can
see what date gets set for Last-Modified and what date it gets back and
uses for comparison on the next request.
Of course, all of that is completely mute if IE is just bypassing the
use of the cache control headers, but it's something that can be checked.
-- Allen
Anil Gangolli wrote:
>
> OK. I confirmed that Roller 2.3 does not send Last-Modified headers for
> certain (possibly all) struts actions, particularly main.do which serves
> the front page in 2.3, but it does send the Last-Modified header for
> blog pages.
>
> Wherever Roller 2.3 does send the header, I see exactly the same issue
> with IE set to the "Automatic" setting, so the issue is not a new
> 3.0-specific one as I had first thought.
>
> What *is* new and initially caught my attention is that in Roller 3.0 we
> now see this staleness behavior in IE on the front page, because the
> front page is actually associated to a blog page, and gets the
> Last-Modified header.
>
> Upshot: I think we should continue the current 3.0 behavior, but I
> won't be surprised if we later get requests to make it configurable, at
> least for the front page to avoid the issue with default IE settings.
> We should wait for that though.
>
>
> --a.
>
>
>
>
> ----- Original Message ----- From: "Anil Gangolli" <an...@busybuddha.org>
> To: <ro...@incubator.apache.org>
> Sent: Sunday, September 03, 2006 11:28 PM
> Subject: Re: problems with 3.0 on IE
>
>
>>
>> Yep. I agree. I'm not sure if there is anything to do here. I'll
>> be trying to understand this further; I'll try to compare what's
>> happening with 2.3 and 3.0 more carefully before making a recommendation.
>>
>>
>> --a.
>>
>>
>> ----- Original Message ----- From: "Allen Gilliland"
>> <al...@sun.com>
>> To: <ro...@incubator.apache.org>
>> Sent: Sunday, September 03, 2006 10:47 PM
>> Subject: Re: problems with 3.0 on IE
>>
>>
>>> eeks. I don't think changing our app to not send Last-Modified
>>> headers is the right approach. The Last-Modified header is an http
>>> standard and if IE is doing something wrong with it then that's their
>>> fault, not ours.
>>>
>>> I think that everything that you listed in your bullets below is
>>> correct behavior for the cache control. A browser can only send an
>>> If-Modified-Since header if it has gotten a Last-Modified header, and
>>> it sounds like when the headers are present (like in firefox) then
>>> everything works properly.
>>>
>>> It's not really our fault if IE is being overly aggressive about its
>>> caching.
>>>
>>> -- Allen
>>>
>>>
>>> Anil Gangolli wrote:
>>>> Scratch the fourth bullet. We are sending a Last-Modified header in
>>>> 2.3, so I still don't know what's different between 3.0 and 2.3
>>>>
>>>> ----- Original Message ----- From: "Anil Gangolli"
>>>> <an...@busybuddha.org>
>>>> To: <ro...@incubator.apache.org>
>>>> Sent: Sunday, September 03, 2006 7:37 PM
>>>> Subject: Re: problems with 3.0 on IE
>>>>
>>>>
>>>>>
>>>>>
>>>>> Here's what I found:
>>>>>
>>>>>
>>>>> - Apparently a recent MS update had reset my caching preferences to
>>>>> allow IE to decide whent to check for modified pages
>>>>> "automatically", (the meaning of which is described here:
>>>>> http://support.microsoft.com/?kbid=263070). In the cases I
>>>>> diagnosed, the browser was indeed, as Allen thought, not even
>>>>> sending a request.
>>>>>
>>>>> - If I change IE's cache control policy to check on "Every visit
>>>>> to the page", I see requests from IE carrying If-Modified-Since
>>>>> headers and what looks like correct cache behavior stepping through
>>>>> PageServlet.
>>>>>
>>>>> - It appears that "Automatically" is the default setting that IE
>>>>> ships with.
>>>>>
>>>>> - If we don't send "Last-Modified" headers and I keep the defaul
>>>>> "Automatically" setting, IE appears to send requests every time,
>>>>> but with no If-Modified-Since header at all.
>>>>>
>>>>> - It appears that in trunk and 2.3 we were not sending the
>>>>> "Last-Modified" header. That code is commented out, without an
>>>>> explanation. (Anyone recall why? Did it have anything to do with
>>>>> IE?) I think this might explain the difference in behavior I'm
>>>>> seeing with 2.3.
>>>>>
>>>>> I think we might want to add a configuration parameter to control
>>>>> whether or not to send the Last-Modified header, or spend more time
>>>>> figuring out a way to work properly with IE's default setting.
>>>>>
>>>>> --a.
>>>>>
>>>>>
>>>>> ----- Original Message ----- From: "Allen Gilliland"
>>>>> <al...@sun.com>
>>>>> To: <ro...@incubator.apache.org>
>>>>> Sent: Saturday, September 02, 2006 11:07 PM
>>>>> Subject: Re: problems with 3.0 on IE
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Anil Gangolli wrote:
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message ----- From: "Allen Gilliland"
>>>>>>> <al...@sun.com>
>>>>>>> To: <ro...@incubator.apache.org>
>>>>>>> Sent: Friday, September 01, 2006 9:18 AM
>>>>>>> Subject: Re: problems with 3.0 on IE
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Anil Gangolli wrote:
>>>>>>>>>
>>>>>>>>> I'm seeing several odd problems with 3.0 on IE 6 on my local
>>>>>>>>> build. I seem to be getting stale versions of pages unless I
>>>>>>>>> load bypassing the cache.
>>>>>>>>
>>>>>>>> I don't see how the caching could be having a different affect
>>>>>>>> from one browser to the next. What do you mean "bypassing the
>>>>>>>> cache"?
>>>>>>>
>>>>>>> I mean forced reload which tells the browser to (a) ignore its
>>>>>>> local cache (b) don't send an If-Modified-Since header.
>>>>>>
>>>>>> gotcha.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> It's possible it's just bad browser caching. I know that
>>>>>>>> firefox can be really tricky with browser caching if you aren't
>>>>>>>> careful, especially with feeds. I know for a fact that there
>>>>>>>> are times in firefox when it won't even sent a request for a
>>>>>>>> page to check 304, it will just automatically use the browser
>>>>>>>> cache, although i haven't figured out the exact conditions for
>>>>>>>> that yet.
>>>>>>>>
>>>>>>>
>>>>>>> I haven't diagnosed it yet, but I suspect it is that we are not
>>>>>>> responding properly to some IfModified-qualified requests.
>>>>>>
>>>>>> That's possible, I never use IE so I can't say that everything is
>>>>>> tested as well in IE. I know that one thing that can cause
>>>>>> problems with if-modified headers is date conversions, if for some
>>>>>> reason IE is doing something even just a few milliseconds
>>>>>> different from the application that can cause the 304 checking to
>>>>>> be wrong.
>>>>>>
>>>>>> -- Allen
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Note: There are no proxies or intermediate servers between the
>>>>>>> browser and my dev Tomcat running on the same host.
>>>>>>>
>>>>>>> Has anyone else seen this with IE on current 3.0 builds? I don't
>>>>>>> want to hold anything up if it is a personal setup issue.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -- Allen
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Is anyone else testing with IE?
>>>>>>>>>
>>>>>>>>> I don't see the same problem with Firefox.
>>>>>>>>>
>>>>>>>>> This is specific to 3.0. I'm not seeing this on 2.3.
>>>>>>>>>
>>>>>>>>> I've just started looking into it, but hesitant to call this a
>>>>>>>>> release candidate without it.
>>>>>>>>>
>>>>>>>>> --a.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: problems with 3.0 on IE
Posted by Anil Gangolli <an...@busybuddha.org>.
OK. I confirmed that Roller 2.3 does not send Last-Modified headers for
certain (possibly all) struts actions, particularly main.do which serves the
front page in 2.3, but it does send the Last-Modified header for blog pages.
Wherever Roller 2.3 does send the header, I see exactly the same issue with
IE set to the "Automatic" setting, so the issue is not a new 3.0-specific
one as I had first thought.
What *is* new and initially caught my attention is that in Roller 3.0 we now
see this staleness behavior in IE on the front page, because the front page
is actually associated to a blog page, and gets the Last-Modified header.
Upshot: I think we should continue the current 3.0 behavior, but I won't be
surprised if we later get requests to make it configurable, at least for the
front page to avoid the issue with default IE settings. We should wait for
that though.
--a.
----- Original Message -----
From: "Anil Gangolli" <an...@busybuddha.org>
To: <ro...@incubator.apache.org>
Sent: Sunday, September 03, 2006 11:28 PM
Subject: Re: problems with 3.0 on IE
>
> Yep. I agree. I'm not sure if there is anything to do here. I'll be
> trying to understand this further; I'll try to compare what's happening
> with 2.3 and 3.0 more carefully before making a recommendation.
>
>
> --a.
>
>
> ----- Original Message -----
> From: "Allen Gilliland" <al...@sun.com>
> To: <ro...@incubator.apache.org>
> Sent: Sunday, September 03, 2006 10:47 PM
> Subject: Re: problems with 3.0 on IE
>
>
>> eeks. I don't think changing our app to not send Last-Modified headers
>> is the right approach. The Last-Modified header is an http standard and
>> if IE is doing something wrong with it then that's their fault, not ours.
>>
>> I think that everything that you listed in your bullets below is correct
>> behavior for the cache control. A browser can only send an
>> If-Modified-Since header if it has gotten a Last-Modified header, and it
>> sounds like when the headers are present (like in firefox) then
>> everything works properly.
>>
>> It's not really our fault if IE is being overly aggressive about its
>> caching.
>>
>> -- Allen
>>
>>
>> Anil Gangolli wrote:
>>> Scratch the fourth bullet. We are sending a Last-Modified header in
>>> 2.3, so I still don't know what's different between 3.0 and 2.3
>>>
>>> ----- Original Message ----- From: "Anil Gangolli" <an...@busybuddha.org>
>>> To: <ro...@incubator.apache.org>
>>> Sent: Sunday, September 03, 2006 7:37 PM
>>> Subject: Re: problems with 3.0 on IE
>>>
>>>
>>>>
>>>>
>>>> Here's what I found:
>>>>
>>>>
>>>> - Apparently a recent MS update had reset my caching preferences to
>>>> allow IE to decide whent to check for modified pages "automatically",
>>>> (the meaning of which is described here:
>>>> http://support.microsoft.com/?kbid=263070). In the cases I diagnosed,
>>>> the browser was indeed, as Allen thought, not even sending a request.
>>>>
>>>> - If I change IE's cache control policy to check on "Every visit to
>>>> the page", I see requests from IE carrying If-Modified-Since headers
>>>> and what looks like correct cache behavior stepping through
>>>> PageServlet.
>>>>
>>>> - It appears that "Automatically" is the default setting that IE ships
>>>> with.
>>>>
>>>> - If we don't send "Last-Modified" headers and I keep the defaul
>>>> "Automatically" setting, IE appears to send requests every time, but
>>>> with no If-Modified-Since header at all.
>>>>
>>>> - It appears that in trunk and 2.3 we were not sending the
>>>> "Last-Modified" header. That code is commented out, without an
>>>> explanation. (Anyone recall why? Did it have anything to do with IE?)
>>>> I think this might explain the difference in behavior I'm seeing with
>>>> 2.3.
>>>>
>>>> I think we might want to add a configuration parameter to control
>>>> whether or not to send the Last-Modified header, or spend more time
>>>> figuring out a way to work properly with IE's default setting.
>>>>
>>>> --a.
>>>>
>>>>
>>>> ----- Original Message ----- From: "Allen Gilliland"
>>>> <al...@sun.com>
>>>> To: <ro...@incubator.apache.org>
>>>> Sent: Saturday, September 02, 2006 11:07 PM
>>>> Subject: Re: problems with 3.0 on IE
>>>>
>>>>
>>>>>
>>>>>
>>>>> Anil Gangolli wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message ----- From: "Allen Gilliland"
>>>>>> <al...@sun.com>
>>>>>> To: <ro...@incubator.apache.org>
>>>>>> Sent: Friday, September 01, 2006 9:18 AM
>>>>>> Subject: Re: problems with 3.0 on IE
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Anil Gangolli wrote:
>>>>>>>>
>>>>>>>> I'm seeing several odd problems with 3.0 on IE 6 on my local build.
>>>>>>>> I seem to be getting stale versions of pages unless I load
>>>>>>>> bypassing the cache.
>>>>>>>
>>>>>>> I don't see how the caching could be having a different affect from
>>>>>>> one browser to the next. What do you mean "bypassing the cache"?
>>>>>>
>>>>>> I mean forced reload which tells the browser to (a) ignore its local
>>>>>> cache (b) don't send an If-Modified-Since header.
>>>>>
>>>>> gotcha.
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> It's possible it's just bad browser caching. I know that firefox
>>>>>>> can be really tricky with browser caching if you aren't careful,
>>>>>>> especially with feeds. I know for a fact that there are times in
>>>>>>> firefox when it won't even sent a request for a page to check 304,
>>>>>>> it will just automatically use the browser cache, although i haven't
>>>>>>> figured out the exact conditions for that yet.
>>>>>>>
>>>>>>
>>>>>> I haven't diagnosed it yet, but I suspect it is that we are not
>>>>>> responding properly to some IfModified-qualified requests.
>>>>>
>>>>> That's possible, I never use IE so I can't say that everything is
>>>>> tested as well in IE. I know that one thing that can cause problems
>>>>> with if-modified headers is date conversions, if for some reason IE is
>>>>> doing something even just a few milliseconds different from the
>>>>> application that can cause the 304 checking to be wrong.
>>>>>
>>>>> -- Allen
>>>>>
>>>>>
>>>>>>
>>>>>> Note: There are no proxies or intermediate servers between the
>>>>>> browser and my dev Tomcat running on the same host.
>>>>>>
>>>>>> Has anyone else seen this with IE on current 3.0 builds? I don't
>>>>>> want to hold anything up if it is a personal setup issue.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -- Allen
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Is anyone else testing with IE?
>>>>>>>>
>>>>>>>> I don't see the same problem with Firefox.
>>>>>>>>
>>>>>>>> This is specific to 3.0. I'm not seeing this on 2.3.
>>>>>>>>
>>>>>>>> I've just started looking into it, but hesitant to call this a
>>>>>>>> release candidate without it.
>>>>>>>>
>>>>>>>> --a.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: problems with 3.0 on IE
Posted by Anil Gangolli <an...@busybuddha.org>.
Yep. I agree. I'm not sure if there is anything to do here. I'll be
trying to understand this further; I'll try to compare what's happening
with 2.3 and 3.0 more carefully before making a recommendation.
--a.
----- Original Message -----
From: "Allen Gilliland" <al...@sun.com>
To: <ro...@incubator.apache.org>
Sent: Sunday, September 03, 2006 10:47 PM
Subject: Re: problems with 3.0 on IE
> eeks. I don't think changing our app to not send Last-Modified headers is
> the right approach. The Last-Modified header is an http standard and if
> IE is doing something wrong with it then that's their fault, not ours.
>
> I think that everything that you listed in your bullets below is correct
> behavior for the cache control. A browser can only send an
> If-Modified-Since header if it has gotten a Last-Modified header, and it
> sounds like when the headers are present (like in firefox) then everything
> works properly.
>
> It's not really our fault if IE is being overly aggressive about its
> caching.
>
> -- Allen
>
>
> Anil Gangolli wrote:
>> Scratch the fourth bullet. We are sending a Last-Modified header in 2.3,
>> so I still don't know what's different between 3.0 and 2.3
>>
>> ----- Original Message ----- From: "Anil Gangolli" <an...@busybuddha.org>
>> To: <ro...@incubator.apache.org>
>> Sent: Sunday, September 03, 2006 7:37 PM
>> Subject: Re: problems with 3.0 on IE
>>
>>
>>>
>>>
>>> Here's what I found:
>>>
>>>
>>> - Apparently a recent MS update had reset my caching preferences to
>>> allow IE to decide whent to check for modified pages "automatically",
>>> (the meaning of which is described here:
>>> http://support.microsoft.com/?kbid=263070). In the cases I diagnosed,
>>> the browser was indeed, as Allen thought, not even sending a request.
>>>
>>> - If I change IE's cache control policy to check on "Every visit to the
>>> page", I see requests from IE carrying If-Modified-Since headers and
>>> what looks like correct cache behavior stepping through PageServlet.
>>>
>>> - It appears that "Automatically" is the default setting that IE ships
>>> with.
>>>
>>> - If we don't send "Last-Modified" headers and I keep the defaul
>>> "Automatically" setting, IE appears to send requests every time, but
>>> with no If-Modified-Since header at all.
>>>
>>> - It appears that in trunk and 2.3 we were not sending the
>>> "Last-Modified" header. That code is commented out, without an
>>> explanation. (Anyone recall why? Did it have anything to do with IE?)
>>> I think this might explain the difference in behavior I'm seeing with
>>> 2.3.
>>>
>>> I think we might want to add a configuration parameter to control
>>> whether or not to send the Last-Modified header, or spend more time
>>> figuring out a way to work properly with IE's default setting.
>>>
>>> --a.
>>>
>>>
>>> ----- Original Message ----- From: "Allen Gilliland"
>>> <al...@sun.com>
>>> To: <ro...@incubator.apache.org>
>>> Sent: Saturday, September 02, 2006 11:07 PM
>>> Subject: Re: problems with 3.0 on IE
>>>
>>>
>>>>
>>>>
>>>> Anil Gangolli wrote:
>>>>>
>>>>>
>>>>> ----- Original Message ----- From: "Allen Gilliland"
>>>>> <al...@sun.com>
>>>>> To: <ro...@incubator.apache.org>
>>>>> Sent: Friday, September 01, 2006 9:18 AM
>>>>> Subject: Re: problems with 3.0 on IE
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Anil Gangolli wrote:
>>>>>>>
>>>>>>> I'm seeing several odd problems with 3.0 on IE 6 on my local build.
>>>>>>> I seem to be getting stale versions of pages unless I load bypassing
>>>>>>> the cache.
>>>>>>
>>>>>> I don't see how the caching could be having a different affect from
>>>>>> one browser to the next. What do you mean "bypassing the cache"?
>>>>>
>>>>> I mean forced reload which tells the browser to (a) ignore its local
>>>>> cache (b) don't send an If-Modified-Since header.
>>>>
>>>> gotcha.
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> It's possible it's just bad browser caching. I know that firefox can
>>>>>> be really tricky with browser caching if you aren't careful,
>>>>>> especially with feeds. I know for a fact that there are times in
>>>>>> firefox when it won't even sent a request for a page to check 304, it
>>>>>> will just automatically use the browser cache, although i haven't
>>>>>> figured out the exact conditions for that yet.
>>>>>>
>>>>>
>>>>> I haven't diagnosed it yet, but I suspect it is that we are not
>>>>> responding properly to some IfModified-qualified requests.
>>>>
>>>> That's possible, I never use IE so I can't say that everything is
>>>> tested as well in IE. I know that one thing that can cause problems
>>>> with if-modified headers is date conversions, if for some reason IE is
>>>> doing something even just a few milliseconds different from the
>>>> application that can cause the 304 checking to be wrong.
>>>>
>>>> -- Allen
>>>>
>>>>
>>>>>
>>>>> Note: There are no proxies or intermediate servers between the
>>>>> browser and my dev Tomcat running on the same host.
>>>>>
>>>>> Has anyone else seen this with IE on current 3.0 builds? I don't want
>>>>> to hold anything up if it is a personal setup issue.
>>>>>
>>>>>
>>>>>
>>>>>> -- Allen
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Is anyone else testing with IE?
>>>>>>>
>>>>>>> I don't see the same problem with Firefox.
>>>>>>>
>>>>>>> This is specific to 3.0. I'm not seeing this on 2.3.
>>>>>>>
>>>>>>> I've just started looking into it, but hesitant to call this a
>>>>>>> release candidate without it.
>>>>>>>
>>>>>>> --a.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: problems with 3.0 on IE
Posted by Allen Gilliland <al...@sun.com>.
eeks. I don't think changing our app to not send Last-Modified headers
is the right approach. The Last-Modified header is an http standard and
if IE is doing something wrong with it then that's their fault, not ours.
I think that everything that you listed in your bullets below is correct
behavior for the cache control. A browser can only send an
If-Modified-Since header if it has gotten a Last-Modified header, and it
sounds like when the headers are present (like in firefox) then
everything works properly.
It's not really our fault if IE is being overly aggressive about its
caching.
-- Allen
Anil Gangolli wrote:
> Scratch the fourth bullet. We are sending a Last-Modified header in
> 2.3, so I still don't know what's different between 3.0 and 2.3
>
> ----- Original Message ----- From: "Anil Gangolli" <an...@busybuddha.org>
> To: <ro...@incubator.apache.org>
> Sent: Sunday, September 03, 2006 7:37 PM
> Subject: Re: problems with 3.0 on IE
>
>
>>
>>
>> Here's what I found:
>>
>>
>> - Apparently a recent MS update had reset my caching preferences to
>> allow IE to decide whent to check for modified pages "automatically",
>> (the meaning of which is described here:
>> http://support.microsoft.com/?kbid=263070). In the cases I diagnosed,
>> the browser was indeed, as Allen thought, not even sending a request.
>>
>> - If I change IE's cache control policy to check on "Every visit to
>> the page", I see requests from IE carrying If-Modified-Since headers
>> and what looks like correct cache behavior stepping through PageServlet.
>>
>> - It appears that "Automatically" is the default setting that IE ships
>> with.
>>
>> - If we don't send "Last-Modified" headers and I keep the defaul
>> "Automatically" setting, IE appears to send requests every time, but
>> with no If-Modified-Since header at all.
>>
>> - It appears that in trunk and 2.3 we were not sending the
>> "Last-Modified" header. That code is commented out, without an
>> explanation. (Anyone recall why? Did it have anything to do with
>> IE?) I think this might explain the difference in behavior I'm
>> seeing with 2.3.
>>
>> I think we might want to add a configuration parameter to control
>> whether or not to send the Last-Modified header, or spend more time
>> figuring out a way to work properly with IE's default setting.
>>
>> --a.
>>
>>
>> ----- Original Message ----- From: "Allen Gilliland"
>> <al...@sun.com>
>> To: <ro...@incubator.apache.org>
>> Sent: Saturday, September 02, 2006 11:07 PM
>> Subject: Re: problems with 3.0 on IE
>>
>>
>>>
>>>
>>> Anil Gangolli wrote:
>>>>
>>>>
>>>> ----- Original Message ----- From: "Allen Gilliland"
>>>> <al...@sun.com>
>>>> To: <ro...@incubator.apache.org>
>>>> Sent: Friday, September 01, 2006 9:18 AM
>>>> Subject: Re: problems with 3.0 on IE
>>>>
>>>>
>>>>>
>>>>>
>>>>> Anil Gangolli wrote:
>>>>>>
>>>>>> I'm seeing several odd problems with 3.0 on IE 6 on my local
>>>>>> build. I seem to be getting stale versions of pages unless I load
>>>>>> bypassing the cache.
>>>>>
>>>>> I don't see how the caching could be having a different affect from
>>>>> one browser to the next. What do you mean "bypassing the cache"?
>>>>
>>>> I mean forced reload which tells the browser to (a) ignore its local
>>>> cache (b) don't send an If-Modified-Since header.
>>>
>>> gotcha.
>>>
>>>
>>>>
>>>>>
>>>>> It's possible it's just bad browser caching. I know that firefox
>>>>> can be really tricky with browser caching if you aren't careful,
>>>>> especially with feeds. I know for a fact that there are times in
>>>>> firefox when it won't even sent a request for a page to check 304,
>>>>> it will just automatically use the browser cache, although i
>>>>> haven't figured out the exact conditions for that yet.
>>>>>
>>>>
>>>> I haven't diagnosed it yet, but I suspect it is that we are not
>>>> responding properly to some IfModified-qualified requests.
>>>
>>> That's possible, I never use IE so I can't say that everything is
>>> tested as well in IE. I know that one thing that can cause problems
>>> with if-modified headers is date conversions, if for some reason IE
>>> is doing something even just a few milliseconds different from the
>>> application that can cause the 304 checking to be wrong.
>>>
>>> -- Allen
>>>
>>>
>>>>
>>>> Note: There are no proxies or intermediate servers between the
>>>> browser and my dev Tomcat running on the same host.
>>>>
>>>> Has anyone else seen this with IE on current 3.0 builds? I don't
>>>> want to hold anything up if it is a personal setup issue.
>>>>
>>>>
>>>>
>>>>> -- Allen
>>>>>
>>>>>
>>>>>>
>>>>>> Is anyone else testing with IE?
>>>>>>
>>>>>> I don't see the same problem with Firefox.
>>>>>>
>>>>>> This is specific to 3.0. I'm not seeing this on 2.3.
>>>>>>
>>>>>> I've just started looking into it, but hesitant to call this a
>>>>>> release candidate without it.
>>>>>>
>>>>>> --a.
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: problems with 3.0 on IE
Posted by Anil Gangolli <an...@busybuddha.org>.
Scratch the fourth bullet. We are sending a Last-Modified header in 2.3, so
I still don't know what's different between 3.0 and 2.3
----- Original Message -----
From: "Anil Gangolli" <an...@busybuddha.org>
To: <ro...@incubator.apache.org>
Sent: Sunday, September 03, 2006 7:37 PM
Subject: Re: problems with 3.0 on IE
>
>
> Here's what I found:
>
>
> - Apparently a recent MS update had reset my caching preferences to allow
> IE to decide whent to check for modified pages "automatically", (the
> meaning of which is described here:
> http://support.microsoft.com/?kbid=263070). In the cases I diagnosed, the
> browser was indeed, as Allen thought, not even sending a request.
>
> - If I change IE's cache control policy to check on "Every visit to the
> page", I see requests from IE carrying If-Modified-Since headers and what
> looks like correct cache behavior stepping through PageServlet.
>
> - It appears that "Automatically" is the default setting that IE ships
> with.
>
> - If we don't send "Last-Modified" headers and I keep the defaul
> "Automatically" setting, IE appears to send requests every time, but with
> no If-Modified-Since header at all.
>
> - It appears that in trunk and 2.3 we were not sending the "Last-Modified"
> header. That code is commented out, without an explanation. (Anyone
> recall why? Did it have anything to do with IE?) I think this might
> explain the difference in behavior I'm seeing with 2.3.
>
> I think we might want to add a configuration parameter to control whether
> or not to send the Last-Modified header, or spend more time figuring out a
> way to work properly with IE's default setting.
>
> --a.
>
>
> ----- Original Message -----
> From: "Allen Gilliland" <al...@sun.com>
> To: <ro...@incubator.apache.org>
> Sent: Saturday, September 02, 2006 11:07 PM
> Subject: Re: problems with 3.0 on IE
>
>
>>
>>
>> Anil Gangolli wrote:
>>>
>>>
>>> ----- Original Message ----- From: "Allen Gilliland"
>>> <al...@sun.com>
>>> To: <ro...@incubator.apache.org>
>>> Sent: Friday, September 01, 2006 9:18 AM
>>> Subject: Re: problems with 3.0 on IE
>>>
>>>
>>>>
>>>>
>>>> Anil Gangolli wrote:
>>>>>
>>>>> I'm seeing several odd problems with 3.0 on IE 6 on my local build. I
>>>>> seem to be getting stale versions of pages unless I load bypassing the
>>>>> cache.
>>>>
>>>> I don't see how the caching could be having a different affect from one
>>>> browser to the next. What do you mean "bypassing the cache"?
>>>
>>> I mean forced reload which tells the browser to (a) ignore its local
>>> cache (b) don't send an If-Modified-Since header.
>>
>> gotcha.
>>
>>
>>>
>>>>
>>>> It's possible it's just bad browser caching. I know that firefox can
>>>> be really tricky with browser caching if you aren't careful, especially
>>>> with feeds. I know for a fact that there are times in firefox when it
>>>> won't even sent a request for a page to check 304, it will just
>>>> automatically use the browser cache, although i haven't figured out the
>>>> exact conditions for that yet.
>>>>
>>>
>>> I haven't diagnosed it yet, but I suspect it is that we are not
>>> responding properly to some IfModified-qualified requests.
>>
>> That's possible, I never use IE so I can't say that everything is tested
>> as well in IE. I know that one thing that can cause problems with
>> if-modified headers is date conversions, if for some reason IE is doing
>> something even just a few milliseconds different from the application
>> that can cause the 304 checking to be wrong.
>>
>> -- Allen
>>
>>
>>>
>>> Note: There are no proxies or intermediate servers between the browser
>>> and my dev Tomcat running on the same host.
>>>
>>> Has anyone else seen this with IE on current 3.0 builds? I don't want
>>> to hold anything up if it is a personal setup issue.
>>>
>>>
>>>
>>>> -- Allen
>>>>
>>>>
>>>>>
>>>>> Is anyone else testing with IE?
>>>>>
>>>>> I don't see the same problem with Firefox.
>>>>>
>>>>> This is specific to 3.0. I'm not seeing this on 2.3.
>>>>>
>>>>> I've just started looking into it, but hesitant to call this a release
>>>>> candidate without it.
>>>>>
>>>>> --a.
>>>>>
>>>>
>>>
>>
>
Re: problems with 3.0 on IE
Posted by Anil Gangolli <an...@busybuddha.org>.
Here's what I found:
- Apparently a recent MS update had reset my caching preferences to allow IE
to decide whent to check for modified pages "automatically", (the meaning of
which is described here: http://support.microsoft.com/?kbid=263070). In
the cases I diagnosed, the browser was indeed, as Allen thought, not even
sending a request.
- If I change IE's cache control policy to check on "Every visit to the
page", I see requests from IE carrying If-Modified-Since headers and what
looks like correct cache behavior stepping through PageServlet.
- It appears that "Automatically" is the default setting that IE ships with.
- If we don't send "Last-Modified" headers and I keep the defaul
"Automatically" setting, IE appears to send requests every time, but with
no If-Modified-Since header at all.
- It appears that in trunk and 2.3 we were not sending the "Last-Modified"
header. That code is commented out, without an explanation. (Anyone recall
why? Did it have anything to do with IE?) I think this might explain the
difference in behavior I'm seeing with 2.3.
I think we might want to add a configuration parameter to control whether or
not to send the Last-Modified header, or spend more time figuring out a way
to work properly with IE's default setting.
--a.
----- Original Message -----
From: "Allen Gilliland" <al...@sun.com>
To: <ro...@incubator.apache.org>
Sent: Saturday, September 02, 2006 11:07 PM
Subject: Re: problems with 3.0 on IE
>
>
> Anil Gangolli wrote:
>>
>>
>> ----- Original Message ----- From: "Allen Gilliland"
>> <al...@sun.com>
>> To: <ro...@incubator.apache.org>
>> Sent: Friday, September 01, 2006 9:18 AM
>> Subject: Re: problems with 3.0 on IE
>>
>>
>>>
>>>
>>> Anil Gangolli wrote:
>>>>
>>>> I'm seeing several odd problems with 3.0 on IE 6 on my local build. I
>>>> seem to be getting stale versions of pages unless I load bypassing the
>>>> cache.
>>>
>>> I don't see how the caching could be having a different affect from one
>>> browser to the next. What do you mean "bypassing the cache"?
>>
>> I mean forced reload which tells the browser to (a) ignore its local
>> cache (b) don't send an If-Modified-Since header.
>
> gotcha.
>
>
>>
>>>
>>> It's possible it's just bad browser caching. I know that firefox can be
>>> really tricky with browser caching if you aren't careful, especially
>>> with feeds. I know for a fact that there are times in firefox when it
>>> won't even sent a request for a page to check 304, it will just
>>> automatically use the browser cache, although i haven't figured out the
>>> exact conditions for that yet.
>>>
>>
>> I haven't diagnosed it yet, but I suspect it is that we are not
>> responding properly to some IfModified-qualified requests.
>
> That's possible, I never use IE so I can't say that everything is tested
> as well in IE. I know that one thing that can cause problems with
> if-modified headers is date conversions, if for some reason IE is doing
> something even just a few milliseconds different from the application that
> can cause the 304 checking to be wrong.
>
> -- Allen
>
>
>>
>> Note: There are no proxies or intermediate servers between the browser
>> and my dev Tomcat running on the same host.
>>
>> Has anyone else seen this with IE on current 3.0 builds? I don't want to
>> hold anything up if it is a personal setup issue.
>>
>>
>>
>>> -- Allen
>>>
>>>
>>>>
>>>> Is anyone else testing with IE?
>>>>
>>>> I don't see the same problem with Firefox.
>>>>
>>>> This is specific to 3.0. I'm not seeing this on 2.3.
>>>>
>>>> I've just started looking into it, but hesitant to call this a release
>>>> candidate without it.
>>>>
>>>> --a.
>>>>
>>>
>>
>
Re: problems with 3.0 on IE
Posted by Allen Gilliland <al...@sun.com>.
Anil Gangolli wrote:
>
>
> ----- Original Message ----- From: "Allen Gilliland"
> <al...@sun.com>
> To: <ro...@incubator.apache.org>
> Sent: Friday, September 01, 2006 9:18 AM
> Subject: Re: problems with 3.0 on IE
>
>
>>
>>
>> Anil Gangolli wrote:
>>>
>>> I'm seeing several odd problems with 3.0 on IE 6 on my local build.
>>> I seem to be getting stale versions of pages unless I load bypassing
>>> the cache.
>>
>> I don't see how the caching could be having a different affect from
>> one browser to the next. What do you mean "bypassing the cache"?
>
> I mean forced reload which tells the browser to (a) ignore its local
> cache (b) don't send an If-Modified-Since header.
gotcha.
>
>>
>> It's possible it's just bad browser caching. I know that firefox can
>> be really tricky with browser caching if you aren't careful,
>> especially with feeds. I know for a fact that there are times in
>> firefox when it won't even sent a request for a page to check 304, it
>> will just automatically use the browser cache, although i haven't
>> figured out the exact conditions for that yet.
>>
>
> I haven't diagnosed it yet, but I suspect it is that we are not
> responding properly to some IfModified-qualified requests.
That's possible, I never use IE so I can't say that everything is tested
as well in IE. I know that one thing that can cause problems with
if-modified headers is date conversions, if for some reason IE is doing
something even just a few milliseconds different from the application
that can cause the 304 checking to be wrong.
-- Allen
>
> Note: There are no proxies or intermediate servers between the browser
> and my dev Tomcat running on the same host.
>
> Has anyone else seen this with IE on current 3.0 builds? I don't want
> to hold anything up if it is a personal setup issue.
>
>
>
>> -- Allen
>>
>>
>>>
>>> Is anyone else testing with IE?
>>>
>>> I don't see the same problem with Firefox.
>>>
>>> This is specific to 3.0. I'm not seeing this on 2.3.
>>>
>>> I've just started looking into it, but hesitant to call this a
>>> release candidate without it.
>>>
>>> --a.
>>>
>>
>
Re: problems with 3.0 on IE
Posted by Anil Gangolli <an...@busybuddha.org>.
----- Original Message -----
From: "Allen Gilliland" <al...@sun.com>
To: <ro...@incubator.apache.org>
Sent: Friday, September 01, 2006 9:18 AM
Subject: Re: problems with 3.0 on IE
>
>
> Anil Gangolli wrote:
>>
>> I'm seeing several odd problems with 3.0 on IE 6 on my local build. I
>> seem to be getting stale versions of pages unless I load bypassing the
>> cache.
>
> I don't see how the caching could be having a different affect from one
> browser to the next. What do you mean "bypassing the cache"?
I mean forced reload which tells the browser to (a) ignore its local cache
(b) don't send an If-Modified-Since header.
>
> It's possible it's just bad browser caching. I know that firefox can be
> really tricky with browser caching if you aren't careful, especially with
> feeds. I know for a fact that there are times in firefox when it won't
> even sent a request for a page to check 304, it will just automatically
> use the browser cache, although i haven't figured out the exact conditions
> for that yet.
>
I haven't diagnosed it yet, but I suspect it is that we are not responding
properly to some IfModified-qualified requests.
Note: There are no proxies or intermediate servers between the browser and
my dev Tomcat running on the same host.
Has anyone else seen this with IE on current 3.0 builds? I don't want to
hold anything up if it is a personal setup issue.
> -- Allen
>
>
>>
>> Is anyone else testing with IE?
>>
>> I don't see the same problem with Firefox.
>>
>> This is specific to 3.0. I'm not seeing this on 2.3.
>>
>> I've just started looking into it, but hesitant to call this a release
>> candidate without it.
>>
>> --a.
>>
>
Re: problems with 3.0 on IE
Posted by Allen Gilliland <al...@sun.com>.
Anil Gangolli wrote:
>
> I'm seeing several odd problems with 3.0 on IE 6 on my local build. I
> seem to be getting stale versions of pages unless I load bypassing the
> cache.
I don't see how the caching could be having a different affect from one
browser to the next. What do you mean "bypassing the cache"?
It's possible it's just bad browser caching. I know that firefox can be
really tricky with browser caching if you aren't careful, especially
with feeds. I know for a fact that there are times in firefox when it
won't even sent a request for a page to check 304, it will just
automatically use the browser cache, although i haven't figured out the
exact conditions for that yet.
-- Allen
>
> Is anyone else testing with IE?
>
> I don't see the same problem with Firefox.
>
> This is specific to 3.0. I'm not seeing this on 2.3.
>
> I've just started looking into it, but hesitant to call this a release
> candidate without it.
>
> --a.
>
problems with 3.0 on IE
Posted by Anil Gangolli <an...@busybuddha.org>.
I'm seeing several odd problems with 3.0 on IE 6 on my local build. I seem
to be getting stale versions of pages unless I load bypassing the cache.
Is anyone else testing with IE?
I don't see the same problem with Firefox.
This is specific to 3.0. I'm not seeing this on 2.3.
I've just started looking into it, but hesitant to call this a release
candidate without it.
--a.
Re: Ready for a 3.0 RC? What about themes/plugins?
Posted by Dave Johnson <sn...@gmail.com>.
It's definitely not too late for new translations (and bug fixes), as
long as they're ready now or in the next couple of days.
- Dave
On 8/31/06, Sean Gilligan <se...@msgilligan.com> wrote:
> What about getting an updated Japanese translation in 3.0? Is it too
> late to put that in or could we do it between RC's?
>
> -- Sean
>
> Dave Johnson wrote:
> > On 8/31/06, Sean Gilligan <se...@msgilligan.com> wrote:
> >> Sean Gilligan wrote:
> >> > If I write a proposal and the committers review and approve, I
> >> believe I
> >> > could have a patch by Aug 15th.
> >> Sorry, I meant SEPTEMBER 15th.
> >
> > We're trying to get an RC out this week, so I'd vote -1 on that just
> > based on timing.
> >
> > However, I'd like to rally folks for a quick follow-on 3.1 release a
> > month after 3.0 to address bugs and minor improvements.
> >
> > - Dave
> >
> >
>
>
Re: Ready for a 3.0 RC? What about themes/plugins?
Posted by Sean Gilligan <se...@msgilligan.com>.
What about getting an updated Japanese translation in 3.0? Is it too
late to put that in or could we do it between RC's?
-- Sean
Dave Johnson wrote:
> On 8/31/06, Sean Gilligan <se...@msgilligan.com> wrote:
>> Sean Gilligan wrote:
>> > If I write a proposal and the committers review and approve, I
>> believe I
>> > could have a patch by Aug 15th.
>> Sorry, I meant SEPTEMBER 15th.
>
> We're trying to get an RC out this week, so I'd vote -1 on that just
> based on timing.
>
> However, I'd like to rally folks for a quick follow-on 3.1 release a
> month after 3.0 to address bugs and minor improvements.
>
> - Dave
>
>
Re: Ready for a 3.0 RC? What about themes/plugins?
Posted by Dave Johnson <sn...@gmail.com>.
On 8/31/06, Sean Gilligan <se...@msgilligan.com> wrote:
> Sean Gilligan wrote:
> > If I write a proposal and the committers review and approve, I believe I
> > could have a patch by Aug 15th.
> Sorry, I meant SEPTEMBER 15th.
We're trying to get an RC out this week, so I'd vote -1 on that just
based on timing.
However, I'd like to rally folks for a quick follow-on 3.1 release a
month after 3.0 to address bugs and minor improvements.
- Dave
Re: Ready for a 3.0 RC? What about themes/plugins?
Posted by Sean Gilligan <se...@msgilligan.com>.
Sean Gilligan wrote:
> If I write a proposal and the committers review and approve, I believe I
> could have a patch by Aug 15th.
Sorry, I meant SEPTEMBER 15th.
-- Sean
Re: Ready for a 3.0 RC? What about themes/plugins?
Posted by Sean Gilligan <se...@msgilligan.com>.
Hi Dave, et. al.
Sorry for reverting to lurker mode for the past few months. :(
I recently installed the 3.0 branch on my MacBook Pro and it looks
really nice. I was wondering what the schedule was going to be. I'm
ready to do some more testing.
I also want to propose an additional 3.0 feature if it is not too late:
A rel="enclosure" plugin for podcasting and videoblogging.
If I write a proposal and the committers review and approve, I believe I
could have a patch by Aug 15th. (I have a web page that discusses the
issue and provides links to specs and other implementations here:
http://www.msgilligan.com/rss-enclosure-bp.html)
Do you think this could make it into 3.0?
Thanks,
Sean
Dave Johnson wrote:
> The docs are up-to-date and bugs are under control.
>
> Here's an issue I'd like to resolve (and document in the Installation
> Guide) before the RC:
>
> We recently decided to ship only a couple of themes and plugins and we
> still need to figure out what to do with the themes and plugins that
> we don't ship with Roller.
>
> I'd like to propose that, not only should we remove them from the
> release, we should also remove them from Apache SVN. We should remove
> them from SVN and move them to the old Roller project at Java.Net and
> make them available for download there. Here's why:
>
> - We've already re-purposed the old Roller project site as the "Roller
> Support" site -- to host LGPL components and plugins/themes that
> depend on LGPL.
>
> - The extra themes and plugins aren't essential to the community of
> developers maintaining Roller. Ideally, Roller should ship with a
> couple really good themes/plugins and the rest should be provided an
> maintained by the community of Roller users.
>
> - By using the "Struts Applications" model, we can encourage more
> theme development by the community. Struts team members established a
> Sourceforge project to host Struts add-ons and contributors who don't
> necessarily have Apache committer status.
>
> - Themes and plugins can use other-licensed components freely, since
> the Roller Support project is not Apache territory.
>
>
> - Dave
>
>
Re: Ready for a 3.0 RC? What about themes/plugins?
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Dave,
I missed this message when I replied to some messages about plugins
and their homes.
Sorry for the noise; I agree with what you are saying here,
especially with regard to repurposing the old Roller site. As long as
it's clear on both sites where active development is done, and what
the rationale is for each site, I think it's an excellent solution.
Is a vote needed to formalize this proposal?
Craig
On Aug 31, 2006, at 9:50 AM, Dave Johnson wrote:
> The docs are up-to-date and bugs are under control.
>
> Here's an issue I'd like to resolve (and document in the Installation
> Guide) before the RC:
>
> We recently decided to ship only a couple of themes and plugins and we
> still need to figure out what to do with the themes and plugins that
> we don't ship with Roller.
>
> I'd like to propose that, not only should we remove them from the
> release, we should also remove them from Apache SVN. We should remove
> them from SVN and move them to the old Roller project at Java.Net and
> make them available for download there. Here's why:
>
> - We've already re-purposed the old Roller project site as the "Roller
> Support" site -- to host LGPL components and plugins/themes that
> depend on LGPL.
>
> - The extra themes and plugins aren't essential to the community of
> developers maintaining Roller. Ideally, Roller should ship with a
> couple really good themes/plugins and the rest should be provided an
> maintained by the community of Roller users.
>
> - By using the "Struts Applications" model, we can encourage more
> theme development by the community. Struts team members established a
> Sourceforge project to host Struts add-ons and contributors who don't
> necessarily have Apache committer status.
>
> - Themes and plugins can use other-licensed components freely, since
> the Roller Support project is not Apache territory.
>
>
> - Dave
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!