cpp-netlib-devel — Developers Mailing List

Re: [cpp-netlib-devel] Task list and 1.0 milestone (Was Re: TODO's in http_integration)

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

Hi Glyn!

On Wed, Aug 13, 2008 at 3:18 PM, Glyn Matthews <gly...@gm...> wrote:
>
> I added a MIME subproject at sf, if we could add tasks there we could be
> able to give Allister a guide for how to progress with this.
>

Sounds good. I'll go take a look.

> Also, more generally, we're quite lazy about updating the tracker and task
> list at sf.  I don't want to overstate its importance, but I think its
> important to track progress.

Guilty. :D I've been having problems staying connected to Sourceforge
lately through HTTPS from the office connection. It's my excuse for
not updating the trackers as often as I'd like, and I think it's
something that's unique to the network set-up from where I am (I hate
transparent proxies and "smart loadbalancers").

> Could we turn this TODO list into tasks, and
> turn a set of tasks into a 1.0 milestone?  We could also close some of the
> tasks in HTTP integration now that some of them have been done.
>

Sounds good to me. I tried updating the ticket for a synchronous HTTP
client, but I'm having trouble staying logged on to Sourceforge. I'll
look for a better way to do this.

Thanks Glyn!

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

Re: [cpp-netlib-devel] TODO's in http_integration

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

On Wed, Aug 13, 2008 at 2:24 PM, Allister Levi Sanchez
<all...@gm...> wrote:
> Hi,
>
> Sorry I've been silent due to a rather busy work week.

No worries. We all have that. ;)

> But this Friday's a
> holiday in France (yehey!) so I'm thinking of working on the MIME part over
> the 3-day weekend.  I've no clear idea how to do it yet, but it should be a
> good learning experience.

Just let me know if you need any help on specific things. I may be
able to share some thoughts either through here or through IM. :)

>
> Till this weekend, cheers!

Have a good one! :)

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

Re: [cpp-netlib-devel] TODO's in http_integration

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

Hi Divye,

On Wed, Aug 13, 2008 at 2:03 PM, Divye Kapoor <div...@gm...> wrote:
> Hi,
>
>>
>> See section 4.2 - Message Headers of RFC 2616 (
>> >> http://www.faqs.org/rfcs/rfc2388.html ).
>> >> Headers can span multiple lines. This would require a change in the
>> >> processing of the headers.
>> >
>> > I meant http://www.faqs.org/rfcs/rfc2616.html
>> >
>>
>> Perhaps we should have a test for that as well to make sure there's a
>> bug in the client in the first place. Can you make this happen with
>> the Python CGI script?
>
> Yes. It can. I'll try to do it tonight. Otherwise it will have to wait for
> the weekend after next as I have a wedding in the family to take care of
> over the next few days.
>

No rush, I can try hacking it, but I'm not confident enough touching
Python CGI code right now.

>>
>> Right now the client does not have a constructor. We can make use of
>> the Boost.Parameter lib to make some of the options easily defined in
>> the client constructor -- like redirect, authentication information,
>> proxy, etc. I'm also thinking for having an overload to each method
>> that allows you to define these options in each call.
>
> Good idea.
>

I'll get on it, but it will need some C++-side unit tests. I'll write
those but I think it's going to take some time to implement the
redirect handling to prevent infinite-looping redirects. There's also
the referrer thing that needs to be defined, but I will need to read
the HTTP docs about it as well.

>>
>> If we can have the Python CGI test return a redirect, perhaps we can
>> expose the bug and test it as well.
>
> The python CGI cannot return a redirect response due to the way the response
> headers are created in the python library code. It pre-empts a 3xx response
> by sending a 200 response before calling the CGI script. As of now, we need
> to find another way to do it: maybe a simple asio app that redirects a
> request to a url on the python server?
>

Hmmm... Can't the CGI Server be set up to recognize a specific URI,
then be told to redirect?

>>
>> How's the POST handler going? :D
>
> The wedding's going to push things back for me for a while, so it will be on
> the hold list. :(
>

No rush, enjoy the wedding. :)

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

[cpp-netlib-devel] Task list and 1.0 milestone (Was Re: TODO's in http_integration)

[Glyn M. <gly...@gm...>]

Hi,

2008/8/13 Allister Levi Sanchez <all...@gm...>

> Hi,
>
> Sorry I've been silent due to a rather busy work week.  But this Friday's a
> holiday in France (yehey!) so I'm thinking of working on the MIME part over
> the 3-day weekend.  I've no clear idea how to do it yet, but it should be a
> good learning experience.
>

No need to apologise for being busy ;)  It's an open source project and your
effort is welcome.

I added a MIME subproject at sf, if we could add tasks there we could be
able to give Allister a guide for how to progress with this.

Also, more generally, we're quite lazy about updating the tracker and task
list at sf.  I don't want to overstate its importance, but I think its
important to track progress.  Could we turn this TODO list into tasks, and
turn a set of tasks into a 1.0 milestone?  We could also close some of the
tasks in HTTP integration now that some of them have been done.

G

Re: [cpp-netlib-devel] TODO's in http_integration

[Allister L. S. <all...@gm...>]

Hi,

Sorry I've been silent due to a rather busy work week.  But this Friday's a
holiday in France (yehey!) so I'm thinking of working on the MIME part over
the 3-day weekend.  I've no clear idea how to do it yet, but it should be a
good learning experience.

Till this weekend, cheers!
Allister

On Wed, Aug 13, 2008 at 6:45 AM, Dean Michael Berris <mik...@gm...
> wrote:

>
> Like I implied, if it has something to do with MIME, we need to write
> that library outside of HTTP. An imaginary MIME library would expose a
> stream interface, and perhaps provide the following:
>
> <code>
>
> using namespace boost::network::mime;
> omimestream multi_part_builder;
> multi_part_builder
>  << content(
>    disposition(
>      "form-data",
>      make_tuple(
>        make_pair("name", "param1")
>        )
>      ),
>    data("param1Value")
>    )
>  << content(
>    disposition(
>      "file",
>      make_tuple(
>        make_pair("name", "file"),
>        make_pair("filename", "filename1.txt")
>        )
>      ),
>    type(
>      "text/plain"
>      ),
>    data(file_stream)
>  ;
>
> ...
> client_.post(request, multi_part_builder.type(),
> multi_part_builder.body());
>
> </code>
>
> This allows us to use the MIME library outside of HTTP and be a usable
> library in itself. In this case, the decoupling of the MIME handling
> from the HTTP implementation will be a good thing.
>
> I'm not saying it shouldn't be our responsibility -- I agree that we
> should make it easier for users -- but how we're going to allow that
> to happen has to fit within the goals of the project, which is
> building a set of extensible components for building network-aware
> applications in C++.
>
> I can write that MIME builder interface with Boost.Proto or from
> scratch, but that would require me to context-switch from the HTTP
> implementation.
>
> If anybody's interested in picking up that piece of the puzzle, or
> would like to be part of the discussion about it, now would be a good
> time to sound off. :D
>
>
>

Re: [cpp-netlib-devel] TODO's in http_integration

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

Hi,


> See section 4.2 - Message Headers of RFC 2616 (
> >> http://www.faqs.org/rfcs/rfc2388.html ).
> >> Headers can span multiple lines. This would require a change in the
> >> processing of the headers.
> >
> > I meant http://www.faqs.org/rfcs/rfc2616.html
> >

Perhaps we should have a test for that as well to make sure there's a
> bug in the client in the first place. Can you make this happen with
> the Python CGI script?
>

Yes. It can. I'll try to do it tonight. Otherwise it will have to wait for
the weekend after next as I have a wedding in the family to take care of
over the next few days.


>
> Right now the client does not have a constructor. We can make use of
> the Boost.Parameter lib to make some of the options easily defined in
> the client constructor -- like redirect, authentication information,
> proxy, etc. I'm also thinking for having an overload to each method
> that allows you to define these options in each call.
>

Good idea.


>
> If we can have the Python CGI test return a redirect, perhaps we can
> expose the bug and test it as well.
>

The python CGI cannot return a redirect response due to the way the response
headers are created in the python library code. It pre-empts a 3xx response
by sending a 200 response before calling the CGI script. As of now, we need
to find another way to do it: maybe a simple asio app that redirects a
request to a url on the python server?


>
> How's the POST handler going? :D
>

The wedding's going to push things back for me for a while, so it will be on
the hold list. :(

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] TODO's in http_integration

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

On Wed, Aug 13, 2008 at 3:39 AM, Divye Kapoor <div...@gm...> wrote:
>
> On Tue, Aug 12, 2008 at 2:24 PM, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>> About multi-part message posting, I have not seen any documentation
>> regarding the semantics for a multi-part POST message. If it has
>> something to do with MIME, then that library has yet to be written
>> external to the HTTP implementation. AFAICT, each HTTP POST Message
>> has a single body, and a single Content-Length and Content-Type
>> headers -- If the actual body is a multi-part message, then I think
>> the body should have to be formed accordingly, and the Content-Type
>> correctly as well to something like 'multi-part/mixed;
>> boundary="some_boundary"'. The HTTP Client will then be sufficient in
>> its current form to be able to do:
>
> The documentation for sending multiple files/form-fields/data via POST
> (multipart data) is in RFC 2388 (copy at
> http://www.faqs.org/rfcs/rfc2388.html ). A quick example of how the body is
> structured for a multipart POST request is located at
> http://www.codeproject.com/KB/cs/multipart_request_C_.aspx
>

Right, thanks.

> I think supporting this feature should be our responsibility. The user
> should not need to deal with the intricacies of structuring the data
> according to the rules of a multipart form. It will be a source of errors in
> the client application. The user should simply provide a content type and
> corresponding stream and we should draft a proper request out of it.
>

Like I implied, if it has something to do with MIME, we need to write
that library outside of HTTP. An imaginary MIME library would expose a
stream interface, and perhaps provide the following:

<code>

using namespace boost::network::mime;
omimestream multi_part_builder;
multi_part_builder
  << content(
    disposition(
      "form-data",
      make_tuple(
        make_pair("name", "param1")
        )
      ),
    data("param1Value")
    )
  << content(
    disposition(
      "file",
      make_tuple(
        make_pair("name", "file"),
        make_pair("filename", "filename1.txt")
        )
      ),
    type(
      "text/plain"
      ),
    data(file_stream)
  ;

...
client_.post(request, multi_part_builder.type(), multi_part_builder.body());

</code>

This allows us to use the MIME library outside of HTTP and be a usable
library in itself. In this case, the decoupling of the MIME handling
from the HTTP implementation will be a good thing.

I'm not saying it shouldn't be our responsibility -- I agree that we
should make it easier for users -- but how we're going to allow that
to happen has to fit within the goals of the project, which is
building a set of extensible components for building network-aware
applications in C++.

I can write that MIME builder interface with Boost.Proto or from
scratch, but that would require me to context-switch from the HTTP
implementation.

If anybody's interested in picking up that piece of the puzzle, or
would like to be part of the discussion about it, now would be a good
time to sound off. :D

>
>>
>> Another thing that may be required is to change the multi-map
>> underlying implementation for HTTP to use a list of std::pair<>'s to
>> preserve ordering. I've read something about the order of occurrence
>> and possible merging of repeating HTTP Headers.
>
> Some information about merging headers is located at
> http://httpd.apache.org/docs/2.2/mod/mod_headers.html
>

Thanks for the link. This is done on the server-side rather than the
client-side?

I think one thing we can do is to "un-merge" the merged headers
received from the server to make it consistent. In the case of merging
client-formed request headers, we can make it optional -- and should
be easy to do.

>> With multi-line headers processing, I'm not sure if this is ever going
>> to be a problem with HTTP -- I'm not sure of the HTTP spec requires
>> that headers be a single line -- but I am a little worried about our
>> lack of HTTP headers checking. Does anybody have experience with
>> special headers that may span multiple lines? Or am I imagining things
>> here? :D
>
> See section 4.2 - Message Headers of RFC 2616 (
> http://www.faqs.org/rfcs/rfc2388.html ).
> Headers can span multiple lines. This would require a change in the
> processing of the headers.
>

Oh bugger. Thanks for the link. Hmmm... Maybe a test would be good to
expose the bug? :D

>
>>
>> One last thing which needs some scrutiny: maybe we should define a
>> User-Agent: header to identify cpp-netlib? :D
>
> Maybe a default User-Agent header can be provided. Any other ideas?
>

A default should be provided unless it's overridden from the request,
I agree. Test, test, test... ;)

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

Re: [cpp-netlib-devel] TODO's in http_integration

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

On Wed, Aug 13, 2008 at 3:45 AM, Divye Kapoor <div...@gm...> wrote:
>>
>> See section 4.2 - Message Headers of RFC 2616 (
>> http://www.faqs.org/rfcs/rfc2388.html ).
>> Headers can span multiple lines. This would require a change in the
>> processing of the headers.
>
> I meant http://www.faqs.org/rfcs/rfc2616.html
>

Okay, thanks. I'll look into it.

Perhaps we should have a test for that as well to make sure there's a
bug in the client in the first place. Can you make this happen with
the Python CGI script?

> Also, right now, we don't support the rather infrequently used TRACE and
> CONNECT methods. Maybe we should for the sake of completeness?
>

Right. This should be trivial given how the client code is structured right now.

> Another thing that struck me was the fact that using the just checked in
> example, if you try to access http://www.google.com - you get a redirect
> response (3xx status code). However, we don't automatically redirect. Should
> the choice to redirect be left to the user or should we give an option to
> enable automatic redirection? Personally, I am in favour of providing an
> option to enable or disable automatic redirection for requests. What do you
> think?
>

I was thinking about that. Actually, even if you just go to
http://boost.org/  you will get a redirect to http://www.boost.org/.

Right now the client does not have a constructor. We can make use of
the Boost.Parameter lib to make some of the options easily defined in
the client constructor -- like redirect, authentication information,
proxy, etc. I'm also thinking for having an overload to each method
that allows you to define these options in each call.

If we can have the Python CGI test return a redirect, perhaps we can
expose the bug and test it as well.

How's the POST handler going? :D

Thanks for the links and responses. They definitely help a lot.

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

Re: [cpp-netlib-devel] Documentation

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

Hi,

>
>
> Come to think of it, now that we've got something pretty usable, maybe
> we should post something to the Boost mailing list about the progress
> we've made so far? Or do you still think it's premature? :D
>

I would say that its still premature. We need better docs and tests before
we inform the boost mailing list.

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] TODO's in http_integration

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

>
>
> See section 4.2 - Message Headers of RFC 2616 (
> http://www.faqs.org/rfcs/rfc2388.html ).
> Headers can span multiple lines. This would require a change in the
> processing of the headers.
>

I meant http://www.faqs.org/rfcs/rfc2616.html

Also, right now, we don't support the rather infrequently used TRACE and
CONNECT methods. Maybe we should for the sake of completeness?

Another thing that struck me was the fact that using the just checked in
example, if you try to access http://www.google.com - you get a redirect
response (3xx status code). However, we don't automatically redirect. Should
the choice to redirect be left to the user or should we give an option to
enable automatic redirection? Personally, I am in favour of providing an
option to enable or disable automatic redirection for requests. What do you
think?

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] TODO's in http_integration

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

Hi,

On Tue, Aug 12, 2008 at 2:24 PM, Dean Michael Berris <mik...@gm...
> wrote:

>
> About multi-part message posting, I have not seen any documentation
> regarding the semantics for a multi-part POST message. If it has
> something to do with MIME, then that library has yet to be written
> external to the HTTP implementation. AFAICT, each HTTP POST Message
> has a single body, and a single Content-Length and Content-Type
> headers -- If the actual body is a multi-part message, then I think
> the body should have to be formed accordingly, and the Content-Type
> correctly as well to something like 'multi-part/mixed;
> boundary="some_boundary"'. The HTTP Client will then be sufficient in
> its current form to be able to do:
>

The documentation for sending multiple files/form-fields/data via POST
(multipart data) is in RFC 2388 (copy at
http://www.faqs.org/rfcs/rfc2388.html ). A quick example of how the body is
structured for a multipart POST request is located at
http://www.codeproject.com/KB/cs/multipart_request_C_.aspx

I think supporting this feature should be our responsibility. The user
should not need to deal with the intricacies of structuring the data
according to the rules of a multipart form. It will be a source of errors in
the client application. The user should simply provide a content type and
corresponding stream and we should draft a proper request out of it.



> Another thing that may be required is to change the multi-map
> underlying implementation for HTTP to use a list of std::pair<>'s to
> preserve ordering. I've read something about the order of occurrence
> and possible merging of repeating HTTP Headers.
>

Some information about merging headers is located at
http://httpd.apache.org/docs/2.2/mod/mod_headers.html

With multi-line headers processing, I'm not sure if this is ever going
to be a problem with HTTP -- I'm not sure of the HTTP spec requires
that headers be a single line -- but I am a little worried about our
lack of HTTP headers checking. Does anybody have experience with
special headers that may span multiple lines? Or am I imagining things
here? :D

See section 4.2 - Message Headers of RFC 2616 (
http://www.faqs.org/rfcs/rfc2388.html ).
Headers can span multiple lines. This would require a change in the
processing of the headers.



> One last thing which needs some scrutiny: maybe we should define a
> User-Agent: header to identify cpp-netlib? :D
>

Maybe a default User-Agent header can be provided. Any other ideas?

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] Documentation

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

On Tue, Aug 12, 2008 at 5:51 PM, Glyn Matthews <gly...@gm...> wrote:
>
>
> 2008/8/12 Dean Michael Berris <mik...@gm...>
>>
>> On Tue, Aug 12, 2008 at 5:13 PM, Glyn Matthews <gly...@gm...>
>> wrote:
>>
>> > * Specializing the message for custom data structures;
>>
>> This one's also a good one. Maybe I can test the vector of pair of
>> strings implementation in an example, and see if I get the correct
>> ordering.
>
> Good.  I was also thinking of specializing it with unordered containers.
>

Might be a good experiment too. I'll see what I can come up with soon.

>>
>> > * A "better" HTTP example than asio (this is to demonstrate the
>> > advantages
>> > of this library as an addition to asio)
>>
>> I think we already have this? Or do you have something else in mind? :D
>
> You added an HTTP client, but I don't see a server that follows the same
> model.
>

Ah, yes.

I'm actually going to talk to the management here at Friendster if
they would like to open source the HTTP server I've implemented
internally to share with a larger community. Last time we had a
similar discussion, it led to the open sourcing of the Memcache++
Client library. That's also the same reason why it took me so long to
get on the client side of HTTP for this project. :D

I can't share more than that, but I do hope the talks work out. :D

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

Re: [cpp-netlib-devel] Documentation

[Glyn M. <gly...@gm...>]

2008/8/12 Dean Michael Berris <mik...@gm...>

> On Tue, Aug 12, 2008 at 5:13 PM, Glyn Matthews <gly...@gm...>
> wrote:
>
> > * Specializing the message for custom data structures;
>
> This one's also a good one. Maybe I can test the vector of pair of
> strings implementation in an example, and see if I get the correct
> ordering.
>

Good.  I was also thinking of specializing it with unordered containers.


>
> > * A "better" HTTP example than asio (this is to demonstrate the
> advantages
> > of this library as an addition to asio)
>
> I think we already have this? Or do you have something else in mind? :D


You added an HTTP client, but I don't see a server that follows the same
model.

G

Re: [cpp-netlib-devel] Documentation

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

On Tue, Aug 12, 2008 at 5:13 PM, Glyn Matthews <gly...@gm...> wrote:
> 2008/8/12 Dean Michael Berris <mik...@gm...>
>>
>> Sounds good to me.
>>
>> Come to think of it, now that we've got something pretty usable, maybe
>> we should post something to the Boost mailing list about the progress
>> we've made so far? Or do you still think it's premature? :D
>
> More motivating examples and more documentation is required, I think.  I'd
> be interested to hear what the criticism of wider audience.
>

Sounds right to me. :D

> Useful examples might include:
> * Specializing the message type for std::wstring

This should be interesting. There's a special message tag in the
tests, it might be nice to make sure that the HTTP client works right
with wstrings as well.

> * Specializing the message for custom data structures;

This one's also a good one. Maybe I can test the vector of pair of
strings implementation in an example, and see if I get the correct
ordering.

> * A "better" HTTP example than asio (this is to demonstrate the advantages
> of this library as an addition to asio)

I think we already have this? Or do you have something else in mind? :D

> * A proxy example

This sounds good (but tricky).

> * SSL

Another interesting thought. Right now I've been hard-coding the use
of sockets that aren't HTTPS aware, so that's something that needs to
be done still. I'm thinking about it right now and it seems like
there's going to be a lot of refactoring to do with the internals of
the HTTP client to support HTTPS and maximize the code re-use. And
we're not even touching the asynchronous client implementation
thought...

> * A simple example demonstrating the use of web services (we can bundle
> tinyjson http://blog.beef.de/projects/tinyjson/ along with the examples, I
> think).
>

This should be a nice exercise for others to jump in and get their
feet wet with the HTTP client. :D

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

Re: [cpp-netlib-devel] Documentation

[Glyn M. <gly...@gm...>]

2008/8/12 Dean Michael Berris <mik...@gm...>

>
> Sounds good to me.
>
> Come to think of it, now that we've got something pretty usable, maybe
> we should post something to the Boost mailing list about the progress
> we've made so far? Or do you still think it's premature? :D
>

More motivating examples and more documentation is required, I think.  I'd
be interested to hear what the criticism of wider audience.

Useful examples might include:
* Specializing the message type for std::wstring
* Specializing the message for custom data structures;
* A "better" HTTP example than asio (this is to demonstrate the advantages
of this library as an addition to asio)
* A proxy example
* SSL
* A simple example demonstrating the use of web services (we can bundle
tinyjson http://blog.beef.de/projects/tinyjson/ along with the examples, I
think).


>
> Have a good day guys! :)
>
You too,
Glyn

Re: [cpp-netlib-devel] Documentation

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

On Tue, Aug 12, 2008 at 3:10 PM, Glyn Matthews <gly...@gm...> wrote:
> Hi,
>
> 2008/8/12 Dean Michael Berris <mik...@gm...>
>>
>> I just checked in one example of using the HTTP client. I'm going to
>> give another example on using the message framework. :)
>
> Yes, I tried it already and it works well :)
>

Sweet! :D

>>
>> > This will do us for starters, I think.  Any comments?  Or suggestions?
>>
>> I like it. If we can generate the docs in HTML and put it up to the
>> sourceforge web space, that would be awesome. :D
>
> Not straight away, but I'd like to have it done soon.  Maybe I'll have some
> time at the weekend, and others can feel free to update it as they wish.
>

Sounds good to me.

Come to think of it, now that we've got something pretty usable, maybe
we should post something to the Boost mailing list about the progress
we've made so far? Or do you still think it's premature? :D

Have a good day guys! :)

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

[cpp-netlib-devel] TODO's in http_integration

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

Hi Guys,

As I've outlined in my latest commit (revision 60:
http://cpp-netlib.svn.sourceforge.net/viewvc/cpp-netlib?view=rev&revision=60)
I have a few items there that may need to be addressed somehow.

TODO:
- multi-line headers processing
- multi-part message posting
- change from multi-map to vector to preserve request header ordering?

With multi-line headers processing, I'm not sure if this is ever going
to be a problem with HTTP -- I'm not sure of the HTTP spec requires
that headers be a single line -- but I am a little worried about our
lack of HTTP headers checking. Does anybody have experience with
special headers that may span multiple lines? Or am I imagining things
here? :D

About multi-part message posting, I have not seen any documentation
regarding the semantics for a multi-part POST message. If it has
something to do with MIME, then that library has yet to be written
external to the HTTP implementation. AFAICT, each HTTP POST Message
has a single body, and a single Content-Length and Content-Type
headers -- If the actual body is a multi-part message, then I think
the body should have to be formed accordingly, and the Content-Type
correctly as well to something like 'multi-part/mixed;
boundary="some_boundary"'. The HTTP Client will then be sufficient in
its current form to be able to do:

  client_.put(request, "multi-part/mixed; boundary=\"some_boundary\"",
my_multipart_mime_body);

Another thing that may be required is to change the multi-map
underlying implementation for HTTP to use a list of std::pair<>'s to
preserve ordering. I've read something about the order of occurrence
and possible merging of repeating HTTP Headers.

One last thing which needs some scrutiny: maybe we should define a
User-Agent: header to identify cpp-netlib? :D

Thanks for the time (if you get this far) and let me know what you think! :)

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

Re: [cpp-netlib-devel] Proxy Support (was Re: Using Boost.Range)

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

On Tue, Aug 12, 2008 at 3:28 PM, Reetesh Mukul <ree...@gm...> wrote:
>
> Though I don't have complete knowledge of proxy, I have played with it
> earlier, and I am planning to play with cpp-netlib and proxy some time
> coming weekend. Accordingly, I will put some test codes there.
>

Sounds good to me, thanks!

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

Re: [cpp-netlib-devel] Proxy Support (was Re: Using Boost.Range)

[Reetesh M. <ree...@gm...>]

Hi Dean,

Though I don't have complete knowledge of proxy, I have played with it
earlier, and I am planning to play with cpp-netlib and proxy some time
coming weekend. Accordingly, I will put some test codes there.

With Regards,
Reetesh Mukul

On Tue, Aug 12, 2008 at 12:42 PM, Dean Michael Berris <
mik...@gm...> wrote:

> Hi Reetesh,
>
> On Tue, Aug 12, 2008 at 3:02 PM, Reetesh Mukul <ree...@gm...>
> wrote:
> > Just show the code, after so long time. Was going through
> http_client.cpp,
> > and it really looks great.
> >
>
> Thanks. :-)
>
> > Sorry for posting under different subject heading, still, is there any
> > support for connecting through proxy ?
> >
>
> Right now, there isn't yet. I still don't have a way to test that
> reliably, or a definitive document on how that should be done.
>
> Anybody with experience working with proxies here?
>
> --
> Dean Michael C. Berris
> Software Engineer, Friendster, Inc.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

[cpp-netlib-devel] Proxy Support (was Re: Using Boost.Range)

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

Hi Reetesh,

On Tue, Aug 12, 2008 at 3:02 PM, Reetesh Mukul <ree...@gm...> wrote:
> Just show the code, after so long time. Was going through http_client.cpp,
> and it really looks great.
>

Thanks. :-)

> Sorry for posting under different subject heading, still, is there any
> support for connecting through proxy ?
>

Right now, there isn't yet. I still don't have a way to test that
reliably, or a definitive document on how that should be done.

Anybody with experience working with proxies here?

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

Re: [cpp-netlib-devel] Documentation

[Glyn M. <gly...@gm...>]

Hi,

2008/8/12 Dean Michael Berris <mik...@gm...>

>
> I just checked in one example of using the HTTP client. I'm going to
> give another example on using the message framework. :)
>

Yes, I tried it already and it works well :)


>
> > This will do us for starters, I think.  Any comments?  Or suggestions?
>
> I like it. If we can generate the docs in HTML and put it up to the
> sourceforge web space, that would be awesome. :D
>

Not straight away, but I'd like to have it done soon.  Maybe I'll have some
time at the weekend, and others can feel free to update it as they wish.

G

[cpp-netlib-devel] Using Boost.Range

[Reetesh M. <ree...@gm...>]

Just show the code, after so long time. Was going through http_client.cpp,
and it really looks great.

Sorry for posting under different subject heading, still, is there any
support for connecting through proxy ?

With Regards,
Reetesh Mukul

On Tue, Aug 12, 2008 at 12:21 PM, Dean Michael Berris <
mik...@gm...> wrote:

> Hi Guys,
>
> I've decided that the headers_range<message>::type should be a
> Boost.Range iterator_range. This greatly simplifies the implementation
> of the headers wrapper, and allows us to re-use the Boost.Range
> framework to play well with range-aware algorithms (coming out in
> Boost.RangeEx).
>
> I've also made changes to the unit tests so that they use the (more
> semantically correct) begin(range) and end(range) instead of
> range.first and range.second.
>
> This should be available in the http_integration branch, revision 59.
>
> Have a good day everyone.
>
> --
> Dean Michael C. Berris
> Software Engineer, Friendster, Inc.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

[cpp-netlib-devel] Using Boost.Range

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

Hi Guys,

I've decided that the headers_range<message>::type should be a
Boost.Range iterator_range. This greatly simplifies the implementation
of the headers wrapper, and allows us to re-use the Boost.Range
framework to play well with range-aware algorithms (coming out in
Boost.RangeEx).

I've also made changes to the unit tests so that they use the (more
semantically correct) begin(range) and end(range) instead of
range.first and range.second.

This should be available in the http_integration branch, revision 59.

Have a good day everyone.

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

Re: [cpp-netlib-devel] Documentation

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

Hi Glyn!

On Tue, Aug 12, 2008 at 4:11 AM, Glyn Matthews <gly...@gm...> wrote:
> Hi,
>
>
> I created a new subversion branch for documentation.  I've added a few a
> quickbook files and an initial Jamfile (copied without shame from the boost
> threads library).
>
> There are some things that need to be done:
>
> 1. We're not an official part of boost, so I don't want to rely too much on
> this connection (I like the way asio does this).  I think it would be a good
> idea for this project to stand up under its own scrutiny before we decide to
> submit it for boost review.  Maybe if someone could come with a small logo,
> it could be good ;)

Sounds like a good idea. I'll ask around for help with regards to a Logo. :)

> 2. I've presented a pretty straightforward documentation template:
>
> - Overview
> - Motivation
> - Message
> - Protocols
> - Acknowledgements
>
> This is pretty uncontroversial and should serve us well.  Adding an examples
> section should be trivial (once we have some examples).
>

I just checked in one example of using the HTTP client. I'm going to
give another example on using the message framework. :)

> This will do us for starters, I think.  Any comments?  Or suggestions?

I like it. If we can generate the docs in HTML and put it up to the
sourceforge web space, that would be awesome. :D

Looking forward to the documentation! :)

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

Re: [cpp-netlib-devel] New http::client code errors

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

On Tue, Aug 12, 2008 at 1:27 AM, Divye Kapoor <div...@gm...> wrote:
> Hi Dean,
>
>>
>> BTW, WRT text_file_query, at this point, I'm at a loss -- maybe Python
>> is also the culprit here, because the response seems to be missing
>> exactly 4 characters (assuming we're missing the \r from the file in
>> the filesystem). Python might be munging the line-endings in Windows?
>> That's the only explanation I can think of at the moment though.
>>
>> Does this manifest when testing against IIS/Apache in Windows? Can
>> anybody test this?
>
> Seems like it. I tested it with IIS7 and the error was gone.
>

Oh, that's good news. Thanks Divye. :)

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