hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Elliot <rob.ell...@ft.com>
Subject Re: Caching responses to HEAD requests in httpclient-cache
Date Thu, 15 May 2014 21:22:46 GMT
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 <jonm@jjmoore.net> 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 <olegk@apache.org>
> wrote:
>
> > On Tue, 2014-05-13 at 11:56 +0100, Rob Elliot wrote:
> > > On 13 May 2014 09:01, Oleg Kalnichevski <olegk@apache.org> 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: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
>
>
> --
> ........
> 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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message