You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by sebb <se...@gmail.com> on 2012/07/09 00:42:35 UTC

Cache-Control: no-cache and no-store

I misunderstood how the "no-cache" attribute is supposed to work.

According to

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

the browser CAN store responses marked as "no-cache", however the
browser MUST revalidate the response.
Without the attribute, then the entry can be re-used without
revalidation provided that it has not expired.

The "no-store" attribute is the one that is intended to prevent
storage of the response in cache.

Re: New Contributor

Posted by Ravidev Gill <ti...@gmail.com>.
Hi Sebb,

Thanks for the reply and for pointing me in the right direction, your help is much appreciated.

I will be looking into the codebase and see if i can pickup a few things and be more active on the mailing chain.

with kind regards,

Ravi Gill.

On Jul 16, 2012, at 9:28 PM, sebb wrote:

> On 16 July 2012 19:57, sebb <se...@gmail.com> wrote:
>> On 12 July 2012 09:46, Ravidev Gill <ti...@gmail.com> wrote:
>>> Hi Guys,
>> 
>> Sorry for the delay in responding.
>> 
>>> I have been following the mailing list for a while now, and have been using Jmeter for last 6 years.
>> 
>> Quite a long time - there have been many changes over that period...
>> 
>>> In the past few years i have written quite a few plugins for jmeter and a framework for reporting around it is are still in use at a few of our customers.
>>> 
>>> I would like to contribute the plugins back to the Community, and would like to participate more actively specifically on jmeter reporting enhancements.
>> 
>> We are always interested in plugins and enhancements.
>> 
>>> Could someone please provide commit rights? and or point me in the right direction ?
>>> 
>> 
>> The ASF is a meritocracy.
>> 
>> People who contribute good quality patches, or new code, or help out
>> in other ways such as documentation and mailing list replies are
>> eligible to be invited to become a committer.
> 
> See also
> 
> http://www.apache.org/foundation/getinvolved.html
> 
> in particular:
> 
> http://www.apache.org/foundation/getinvolved.html#become-a-committer
> 
>> Unfortunately we don't have any JMeter-specific documentation on
>> becoming a committer.
>> Some other projects have produced some docs:
>> 
>> http://forrest.apache.org/committed.html
>> http://activemq.apache.org/becoming-a-committer.html
>> http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html
>> [There is no JMeter school, but the first part of the document gives
>> some general advice]
>> 
>> You can probably find some more with a web search.


Re: New Contributor

Posted by sebb <se...@gmail.com>.
On 16 July 2012 19:57, sebb <se...@gmail.com> wrote:
> On 12 July 2012 09:46, Ravidev Gill <ti...@gmail.com> wrote:
>> Hi Guys,
>
> Sorry for the delay in responding.
>
>> I have been following the mailing list for a while now, and have been using Jmeter for last 6 years.
>
> Quite a long time - there have been many changes over that period...
>
>> In the past few years i have written quite a few plugins for jmeter and a framework for reporting around it is are still in use at a few of our customers.
>>
>> I would like to contribute the plugins back to the Community, and would like to participate more actively specifically on jmeter reporting enhancements.
>
> We are always interested in plugins and enhancements.
>
>> Could someone please provide commit rights? and or point me in the right direction ?
>>
>
> The ASF is a meritocracy.
>
> People who contribute good quality patches, or new code, or help out
> in other ways such as documentation and mailing list replies are
> eligible to be invited to become a committer.

See also

http://www.apache.org/foundation/getinvolved.html

in particular:

http://www.apache.org/foundation/getinvolved.html#become-a-committer

> Unfortunately we don't have any JMeter-specific documentation on
> becoming a committer.
> Some other projects have produced some docs:
>
> http://forrest.apache.org/committed.html
> http://activemq.apache.org/becoming-a-committer.html
> http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html
> [There is no JMeter school, but the first part of the document gives
> some general advice]
>
> You can probably find some more with a web search.

Re: New Contributor

Posted by sebb <se...@gmail.com>.
On 12 July 2012 09:46, Ravidev Gill <ti...@gmail.com> wrote:
> Hi Guys,

Sorry for the delay in responding.

> I have been following the mailing list for a while now, and have been using Jmeter for last 6 years.

Quite a long time - there have been many changes over that period...

> In the past few years i have written quite a few plugins for jmeter and a framework for reporting around it is are still in use at a few of our customers.
>
> I would like to contribute the plugins back to the Community, and would like to participate more actively specifically on jmeter reporting enhancements.

We are always interested in plugins and enhancements.

> Could someone please provide commit rights? and or point me in the right direction ?
>

The ASF is a meritocracy.

People who contribute good quality patches, or new code, or help out
in other ways such as documentation and mailing list replies are
eligible to be invited to become a committer.

Unfortunately we don't have any JMeter-specific documentation on
becoming a committer.
Some other projects have produced some docs:

http://forrest.apache.org/committed.html
http://activemq.apache.org/becoming-a-committer.html
http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html
[There is no JMeter school, but the first part of the document gives
some general advice]

You can probably find some more with a web search.

New Contributor

Posted by Ravidev Gill <ti...@gmail.com>.
Hi Guys,

I have been following the mailing list for a while now, and have been using Jmeter for last 6 years.

In the past few years i have written quite a few plugins for jmeter and a framework for reporting around it is are still in use at a few of our customers.

I would like to contribute the plugins back to the Community, and would like to participate more actively specifically on jmeter reporting enhancements.

Could someone please provide commit rights? and or point me in the right direction ?

with kind regards,

Ravi Gill

Re: Cache-Control: no-cache and no-store

Posted by Milamber <mi...@apache.org>.

Le 08/07/2012 23:42, sebb a ecrit :
> I misunderstood how the "no-cache" attribute is supposed to work.
>
> According to
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
>
> the browser CAN store responses marked as "no-cache", however the
> browser MUST revalidate the response.
> Without the attribute, then the entry can be re-used without
> revalidation provided that it has not expired.
>
> The "no-store" attribute is the one that is intended to prevent
> storage of the response in cache.
>
>   
Some responses for how to interpret the rfc:
https://developer.mozilla.org/en/HTTP_Caching_FAQ




Re: Cache-Control: no-cache and no-store

Posted by sebb <se...@gmail.com>.
On 9 July 2012 16:29, sebb <se...@gmail.com> wrote:
> On 9 July 2012 06:45, Philippe Mouawad <ph...@gmail.com> wrote:
>> Hello Sebb,
>> I understand no-store differently,
>> For me it means do not store on disk but you CAN store it on volatile
>> storage, so in our case, we should store it in cache.
>
> Possibly.
>
>> For me current implémentation is correct
>
> Not sure we are correct now.
> We no longer store responses at all for "no-cache".
> This means they cannot be revalidated.
>
> AIUI, if the revalidate says that the no-cache response is still up to
> date, a browser can use it.
> However the browser must not use the cached entry without checking
> first; in other words, it should ignore the expires date.
>
> So I think the check for no-cache should be done as part of the
> useExpires conditional (as originally proposed by Philippe, and
> wrongly rejected by me). If no-cache is present, store null in the
> expires field; this will stop the entry from being directly returned.

This has now been implemented.

>> as we say That we don't interpret
>> other attributes for example must-revalidate.
>
> That was for simplicity in the initial implementation.
> We could do so later.
>
>> Regards
>> Philippe
>>
>> On Monday, July 9, 2012, sebb wrote:
>>
>>> I misunderstood how the "no-cache" attribute is supposed to work.
>>>
>>> According to
>>>
>>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
>>>
>>> the browser CAN store responses marked as "no-cache", however the
>>> browser MUST revalidate the response.
>>> Without the attribute, then the entry can be re-used without
>>> revalidation provided that it has not expired.
>>>
>>> The "no-store" attribute is the one that is intended to prevent
>>> storage of the response in cache.
>>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.

Re: Cache-Control: no-cache and no-store

Posted by sebb <se...@gmail.com>.
On 9 July 2012 06:45, Philippe Mouawad <ph...@gmail.com> wrote:
> Hello Sebb,
> I understand no-store differently,
> For me it means do not store on disk but you CAN store it on volatile
> storage, so in our case, we should store it in cache.

Possibly.

> For me current implémentation is correct

Not sure we are correct now.
We no longer store responses at all for "no-cache".
This means they cannot be revalidated.

AIUI, if the revalidate says that the no-cache response is still up to
date, a browser can use it.
However the browser must not use the cached entry without checking
first; in other words, it should ignore the expires date.

So I think the check for no-cache should be done as part of the
useExpires conditional (as originally proposed by Philippe, and
wrongly rejected by me). If no-cache is present, store null in the
expires field; this will stop the entry from being directly returned.

> as we say That we don't interpret
> other attributes for example must-revalidate.

That was for simplicity in the initial implementation.
We could do so later.

> Regards
> Philippe
>
> On Monday, July 9, 2012, sebb wrote:
>
>> I misunderstood how the "no-cache" attribute is supposed to work.
>>
>> According to
>>
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
>>
>> the browser CAN store responses marked as "no-cache", however the
>> browser MUST revalidate the response.
>> Without the attribute, then the entry can be re-used without
>> revalidation provided that it has not expired.
>>
>> The "no-store" attribute is the one that is intended to prevent
>> storage of the response in cache.
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: Cache-Control: no-cache and no-store

Posted by Philippe Mouawad <ph...@gmail.com>.
Hello Sebb,
I understand no-store differently,
For me it means do not store on disk but you CAN store it on volatile
storage, so in our case, we should store it in cache.
For me current implémentation is correct as we say That we don't interpret
other attributes for example must-revalidate.

Regards
Philippe

On Monday, July 9, 2012, sebb wrote:

> I misunderstood how the "no-cache" attribute is supposed to work.
>
> According to
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
>
> the browser CAN store responses marked as "no-cache", however the
> browser MUST revalidate the response.
> Without the attribute, then the entry can be re-used without
> revalidation provided that it has not expired.
>
> The "no-store" attribute is the one that is intended to prevent
> storage of the response in cache.
>


-- 
Cordialement.
Philippe Mouawad.