Sorry to be tardy replying. Thanks, Jon - hopefully we'll be able to have a crack at this soon.
Rob On 13 May 2014 17:22, Jon Moore <[email protected]> wrote: > Hi folks, > > I think extending the cache module to support caching HEAD would be very > welcome, and I think you've identified the overall constraints (cached HEAD > responses can satisfy HEAD requests but GET requests still require an > origin request). I think it would be also valuable to allow HEAD requests > to be satisfied from cached responses to previous GETs, but that can > certainly come as a second step if desired. > > A clean patch with good unit test coverage for this will almost certainly > get accepted in one form or another. One other constraint is that we try > very hard to maintain binary backwards-compatibility in the non-private > parts of HttpClient and its associated modules, so bear that in mind if you > find you need to do refactoring. In any event, the right way forward is to > open a JIRA issue, and as you run across issues we can discuss approaches > there. > > Thanks for your interest in making this contribution! > > Jon > > > > On Tue, May 13, 2014 at 7:34 AM, Oleg Kalnichevski <[email protected]> > wrote: > > > On Tue, 2014-05-13 at 11:56 +0100, Rob Elliot wrote: > > > On 13 May 2014 09:01, Oleg Kalnichevski <[email protected]> wrote: > > > > > > > > On Mon, 2014-05-12 at 13:48 +0100, Rob Elliot wrote: > > > > > > > > > > We're considering extending httpclient-cache to make [it cache the > > > responses > > > > > to HEAD requests], but we > > > > > don't want to lock ourselves out of upgrading forever. If we were > to > > do > > > so > > > > > and offer to contribute it back to the project would you be > > interested? > > > > > > > > > > Regards, > > > > > Rob > > > > > > > > > > > > > The best course of action would be to raise a JIRA with a change > > request > > > > and attach propose changes as a patch in udiff format. Alternatively > > you > > > > might want to fork httpclient in github [1] and open a pull request > > with > > > > the project. > > > > > > > > > > Thanks, Oleg. Can I take it from this that you would be receptive to > this > > > change? > > > It'd be good to know that, provided we implement it well, it would be > > > likely to be > > > accepted before we steam ahead and do it. > > > > > > Thanks, > > > Rob > > > > > > > Rob, > > > > I generally try to stay away from anything cache related. I hope Jon or > > Francois-Xavier can comment whether or not the proposed change is likely > > to get accepted. > > > > Generally, a well engineered patch that comes with a decent test > > coverage is likely to get incorporated in one way or another. Even _if_ > > the whole idea got rejected we could still try to make the caching > > module extensible in such a way as to enable you to plug in some > > non-standard custom code to archive the desired effect without having to > > fork the framework. > > > > Oleg > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > -- > ........ > Jon Moore > -- ------------------------------ This email was sent by a company owned by Pearson plc, registered office at 80 Strand, London WC2R 0RL. Registered in England and Wales with company number 53723.
