cpp-netlib-devel

[cpp-netlib-devel] [http][client] Constructor Options

[Dean M. B. <mik...@gm...>]

Hi Guys,

I'd just like to post on the list two additional constructor options
which the http::client now supports (mainly a brain dump for
documentation):

Enabling http::client features can be done by passing constructor
options. These two new constructor options are:

* http::client::cache_resolved -- enable caching of resolved
endpoints, to prevent the client from resolving IP addresses of
previously resolved hostnames
* http::client::follow_redirects / http::client::follow_redirect --
follow HTTP redirect(s) (300..307) by looking at the "Location" header
provided by the response(s); headers present in the original request
are preserved in the subsequent request(s).

A new member function 'clear_cached()' has been added to clear the
resolved endpoint cache.

The following are TODO's related to these two new features:
- Expiring resolved cached endpoints (configurable?)
- Limiting the depth of redirect resolution (configurable?)
- Use Boost.Parameters library to enable named parameters

The default behavior of the http::client (when default constructed) is to:
* NOT cache resolved endpoints
* NOT follow redirects

Questions and discussion most welcome (this is in preparation for release 0.3)

HTH!

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] [http][client] Constructor Options

[K. G. <kim...@gm...>]

Hi Dean,

Looks cool!

On Mon, Sep 8, 2008 at 07:51, Dean Michael Berris
<mik...@gm...> wrote:
>
> * http::client::follow_redirects / http::client::follow_redirect --

I took this to mean there are two options -- what's the difference
between follow_redirects and follow_redirect? How far it follows?

> The following are TODO's related to these two new features:
> - Expiring resolved cached endpoints (configurable?)
> - Limiting the depth of redirect resolution (configurable?)

This got me thinking about the corner case of circular redirects -- a
depth limit would solve that. Should the limit have a conservative
default?

Thanks,
- Kim

Re: [cpp-netlib-devel] [http][client] Constructor Options

[Dean M. B. <mik...@gm...>]

On Mon, Sep 8, 2008 at 2:47 PM, Kim Gräsman <kim...@gm...> wrote:
> Hi Dean,
>
> Looks cool!
>
> On Mon, Sep 8, 2008 at 07:51, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>> * http::client::follow_redirects / http::client::follow_redirect --
>
> I took this to mean there are two options -- what's the difference
> between follow_redirects and follow_redirect? How far it follows?
>

Nope, you can use either option to mean the same thing.

>> The following are TODO's related to these two new features:
>> - Expiring resolved cached endpoints (configurable?)
>> - Limiting the depth of redirect resolution (configurable?)
>
> This got me thinking about the corner case of circular redirects -- a
> depth limit would solve that. Should the limit have a conservative
> default?
>

Right now it doesn't. I'm still thinking about how to go about it.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] [http][client] Constructor Options

[Divye K. <div...@gm...>]

Hello Dean,

On Mon, Sep 8, 2008 at 11:21 AM, Dean Michael Berris <mik...@gm...
> wrote:

>
> A new member function 'clear_cached()' has been added to clear the
> resolved endpoint cache.
>
> On a point of clarity, shouldn't that function be renamed to
clear_resolved_cache()? clear_cached() doesn't specify what cache is being
cleared.

Divye

-- 
An idealist is one who, on noticing that a rose smells better than a
cabbage, concludes that it will also make better soup.
H. L. Mencken (1880 - 1956)
My official web site: http://people.iitr.ernet.in/shp/061305/
Webmaster: http://www.drkapoorsclinic.com
Blog: http://divyekapoor.blogspot.com

Re: [cpp-netlib-devel] [http][client] Constructor Options

[Dean M. B. <mik...@gm...>]

On Mon, Sep 8, 2008 at 9:50 PM, Divye Kapoor <div...@gm...> wrote:
> Hello Dean,
>
> On Mon, Sep 8, 2008 at 11:21 AM, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>> A new member function 'clear_cached()' has been added to clear the
>> resolved endpoint cache.
>>
> On a point of clarity, shouldn't that function be renamed to
> clear_resolved_cache()? clear_cached() doesn't specify what cache is being
> cleared.
>

Ah, yes. ;-)

I wasn't looking into adding caching to the client yet -- and I was
thinking it may be implied that the only thing cached are the resolved
endpoints.

I'll think about it before we tag for release 0.3.

clear_resolved_cache() is a little long. Any other names?

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.