Menu
▾
▴
cpp-netlib-devel — Developers Mailing List
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(52) |
Jun
(30) |
Jul
(17) |
Aug
(9) |
Sep
(4) |
Oct
(7) |
Nov
(11) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(1) |
Mar
(37) |
Apr
(28) |
May
(15) |
Jun
(28) |
Jul
(7) |
Aug
(125) |
Sep
(116) |
Oct
(85) |
Nov
(14) |
Dec
(6) |
| 2009 |
Jan
(11) |
Feb
(4) |
Mar
(5) |
Apr
|
May
(9) |
Jun
(5) |
Jul
(4) |
Aug
(40) |
Sep
(1) |
Oct
(19) |
Nov
(43) |
Dec
(45) |
| 2010 |
Jan
(76) |
Feb
(95) |
Mar
(3) |
Apr
(23) |
May
(39) |
Jun
(54) |
Jul
(6) |
Aug
(13) |
Sep
(12) |
Oct
(59) |
Nov
(53) |
Dec
(43) |
| 2011 |
Jan
(43) |
Feb
(44) |
Mar
(25) |
Apr
(23) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(1) |
Nov
(2) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
|
From: Raindog <ra...@ma...> - 2010-12-27 19:32:23
|
On 12/26/2010 5:28 PM, Dean Michael Berris wrote: > On Mon, Dec 27, 2010 at 3:46 AM, Jeroen Habraken <vex...@gm...> wrote: > > On 26 December 2010 15:57, Dean Michael Berris <mik...@gm...> wrote: > >> On Fri, Dec 24, 2010 at 9:39 PM, Jeroen Habraken <vex...@gm...> wrote: > >>> Just ran into https://github.com/ry/http-parser, which might be nice > >>> to integrate. > >>> > >> > >> Interesting. Thanks Jeroen, I'll take a look at this at some point. > >> It's just been crazy for me lately. > >> > >> Can you give me at least a high-level idea of what I should be looking at here? > > > > Sure, this is a RFC compliant HTTP parser, and there are a couple of > > things which might be of interest. First of all, it's a switch-case > > style parser, thus the case's they've chosen might be of interest. > > Secondly, and more importantly, it comes with quite a neat test set > > which might help you in your TDD approach. > > > > Interesting. > > I see that it's written in C, but I'm not sure what license they use > for the code. > > That said, I already have an incremental parser in the library for > both requests and responses. I don't see why I'll need another > implementation in there. ;) > > /me was secretly hoping that it was written in Spirit. :P > > Thanks again Jeroen, I'll think more about it. > If his test cases are complete, it would be a nice way to test cpp-netlib. |
|
From: Dean M. B. <mik...@gm...> - 2010-12-27 01:28:47
|
On Mon, Dec 27, 2010 at 3:46 AM, Jeroen Habraken <vex...@gm...> wrote: > On 26 December 2010 15:57, Dean Michael Berris <mik...@gm...> wrote: >> On Fri, Dec 24, 2010 at 9:39 PM, Jeroen Habraken <vex...@gm...> wrote: >>> Just ran into https://github.com/ry/http-parser, which might be nice >>> to integrate. >>> >> >> Interesting. Thanks Jeroen, I'll take a look at this at some point. >> It's just been crazy for me lately. >> >> Can you give me at least a high-level idea of what I should be looking at here? > > Sure, this is a RFC compliant HTTP parser, and there are a couple of > things which might be of interest. First of all, it's a switch-case > style parser, thus the case's they've chosen might be of interest. > Secondly, and more importantly, it comes with quite a neat test set > which might help you in your TDD approach. > Interesting. I see that it's written in C, but I'm not sure what license they use for the code. That said, I already have an incremental parser in the library for both requests and responses. I don't see why I'll need another implementation in there. ;) /me was secretly hoping that it was written in Spirit. :P Thanks again Jeroen, I'll think more about it. -- Dean Michael Berris about.me/deanberris |
|
From: Jeroen H. <vex...@gm...> - 2010-12-26 19:46:29
|
Hi, On 26 December 2010 15:57, Dean Michael Berris <mik...@gm...> wrote: > On Fri, Dec 24, 2010 at 9:39 PM, Jeroen Habraken <vex...@gm...> wrote: >> Just ran into https://github.com/ry/http-parser, which might be nice >> to integrate. >> > > Interesting. Thanks Jeroen, I'll take a look at this at some point. > It's just been crazy for me lately. > > Can you give me at least a high-level idea of what I should be looking at here? Sure, this is a RFC compliant HTTP parser, and there are a couple of things which might be of interest. First of all, it's a switch-case style parser, thus the case's they've chosen might be of interest. Secondly, and more importantly, it comes with quite a neat test set which might help you in your TDD approach. > -- > Dean Michael Berris > about.me/deanberris Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-12-26 14:58:19
|
On Fri, Dec 24, 2010 at 9:39 PM, Jeroen Habraken <vex...@gm...> wrote: > Just ran into https://github.com/ry/http-parser, which might be nice > to integrate. > Interesting. Thanks Jeroen, I'll take a look at this at some point. It's just been crazy for me lately. Can you give me at least a high-level idea of what I should be looking at here? -- Dean Michael Berris about.me/deanberris |
|
From: Jeroen H. <vex...@gm...> - 2010-12-24 13:39:55
|
Just ran into https://github.com/ry/http-parser, which might be nice to integrate. Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-12-13 01:08:00
|
Hi Emre, On Mon, Dec 13, 2010 at 4:56 AM, Emre Türkay <emr...@gm...> wrote: > Hi, I've got a compile error on: Mac OSX, gcc: 4.2.1, boost: 1.44. > Yeah, unfortunately cpp-netlib is known to be broken on compilers that are older than GCC 4.4 (I'm not sure about 4.3) because of the template tricks the asynchronous server implementation uses. My target is to make it work on 4.1.2 so that others with older versions of GCC can use it. Thanks for the report, I'll see if I can address this on 0.8.1 and 0.9. Support for older versions of GCC is in my TODO list, and it's high up there. -- Dean Michael Berris deanberris.com |
|
From: Emre T. <emr...@gm...> - 2010-12-12 20:56:59
|
Hi, I've got a compile error on: Mac OSX, gcc: 4.2.1, boost: 1.44.
mkdir build
cd build
cmake ..
make
[ 4%] Building CXX object libs/network/test/CMakeFiles/cpp-netlib-hello_world.dir/hello_world.cpp.o
In file included from /Users/user/Documents/Sources/Downloads/cpp-netlib-0.8/boost/network/protocol/http/server/async_server.hpp:9,
from /Users/user/Documents/Sources/Downloads/cpp-netlib-0.8/boost/network/protocol/http/server.hpp:15,
from /Users/user/Documents/Sources/Downloads/cpp-netlib-0.8/libs/network/test/hello_world.cpp:10:
/Users/user/Documents/Sources/Downloads/cpp-netlib-0.8/boost/network/protocol/http/server/async_connection.hpp: In member function ‘void boost::network::http::async_connection<Tag, Handler>::continue_write(Range, boost::function<void ()(boost::system::error_code)>)’:
/Users/user/Documents/Sources/Downloads/cpp-netlib-0.8/boost/network/protocol/http/server/async_connection.hpp:495: error: expected primary-expression before ‘>’ token
/Users/user/Documents/Sources/Downloads/cpp-netlib-0.8/boost/network/protocol/http/server/async_connection.hpp:496: error: expected primary-expression before ‘,’ token
/Users/user/Documents/Sources/Downloads/cpp-netlib-0.8/boost/network/protocol/http/server/async_connection.hpp: In member function ‘void boost::network::http::async_connection<Tag, Handler>::write_impl(Range, boost::function<void ()(boost::system::error_code)>)’:
/Users/user/Documents/Sources/Downloads/cpp-netlib-0.8/boost/network/protocol/http/server/async_connection.hpp:592: error: expected primary-expression before ‘>’ token
/Users/user/Documents/Sources/Downloads/cpp-netlib-0.8/boost/network/protocol/http/server/async_connection.hpp:593: error: expected primary-expression before ‘,’ token
/Users/user/Documents/Sources/Downloads/cpp-netlib-0.8/boost/network/protocol/http/server/async_connection.hpp:600: error: expected primary-expression before ‘>’ token
/Users/user/Documents/Sources/Downloads/cpp-netlib-0.8/boost/network/protocol/http/server/async_connection.hpp:601: error: expected primary-expression before ‘,’ token
make[2]: *** [libs/network/test/CMakeFiles/cpp-netlib-hello_world.dir/hello_world.cpp.o] Error 1
make[1]: *** [libs/network/test/CMakeFiles/cpp-netlib-hello_world.dir/all] Error 2
make: *** [all] Error 2
|
|
From: Dean M. B. <mik...@gm...> - 2010-12-12 09:29:05
|
On Sat, Dec 11, 2010 at 12:57 PM, Chatsiri Ratana <ins...@gm...> wrote: > > On Fri, Dec 10, 2010 at 9:08 PM, Dean Michael Berris > <mik...@gm...> wrote: >> >> Hi Guys, >> >> Today I just finished changing the HTTP Client and HTTP Server >> constructor interfaces to use Boost.Parameter. I added tests for the >> server constructor interfaces. This basically allows users to write: >> >> using namespace boost::network::http; >> server instance(_address="0.0.0.0", _port="8000", >> _io_service=my_io_service, _handler=my_handler, >> _reuse_address=true); >> > > I saw old example version 0.8. It's not clear when using code above.Could > you show document or example for me? What do you mean it's not clear when using code above? This only affects 0.9. Also, code that used to compile with 0.8 should still compile in 0.9. It's just that there are additional Boost.Parameter options supported in 0.9-devel. -- Dean Michael Berris deanberris.com |
|
From: Chatsiri R. <ins...@gm...> - 2010-12-11 04:57:28
|
On Fri, Dec 10, 2010 at 9:08 PM, Dean Michael Berris <mik...@gm... > wrote: > Hi Guys, > > Today I just finished changing the HTTP Client and HTTP Server > constructor interfaces to use Boost.Parameter. I added tests for the > server constructor interfaces. This basically allows users to write: > > using namespace boost::network::http; > server instance(_address="0.0.0.0", _port="8000", > _io_service=my_io_service, _handler=my_handler, > _reuse_address=true); > > I saw old example version 0.8. It's not clear when using code above.Could you show document or example for me? The supported parameters will be documented accordingly. > > Note though that the server constructor interface change is backward > compatible, meaning all previous code that compiled with the server > constructor will still build. > > The client constructor interface though is a breaking change. > Basically, what used to be: > > http::client instance(http::client::cache_resolved); > > Is now: > > http::client instance(http::_cache_resolved=true); > > This will break code that was written in the old style of the client > interface. > > Because of this, I'm going to be releasing 0.8.1 which will include a > number of enhancements to the 0.8 implementation, while 0.9 will be a > different "branch". 0.9's client implementation is not source > compatible with code which will be using 0.8 HTTP client interface. > I'm willing to support the 0.8 line for one year, of course subject to > my availability. Commercial support for the 0.8 line is also still > available, contact me for details of that. ;) > > The 0.9 release will also introduce external linkage dependencies, > mainly to the externalized parsers for the HTTP client and the > servers. > > Thanks everyone and I hope this helps. > > -- > Dean Michael Berris > deanberris.com > > > ------------------------------------------------------------------------------ > _______________________________________________ > Cpp-netlib-devel mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel > -- :-------------------------------------------------------- weblog :http://www.chatsiri.com,profile: http://www.linkedin.com/in/chatsiri |
|
From: Dean M. B. <mik...@gm...> - 2010-12-10 14:30:13
|
Hi Everyone, I'm nearing the end of the feature implementation for cpp-netlib's 0.9 release. I suggest that someone (Glyn/Jeroen?) look at the failing URL tests in 0.9-devel and help out with making them pass. I'm a little confused as to why the HTTP URL test is failing, and it might have something to do with the wide character support implementation being broken. I'd go in there and look around, but I'm afraid there will be quite a lot of duplication that will happen if in case I try to implement the same URI grammar for wide character URI's. Insight and most definitely help would be most appreciated. Thanks in advance guys! -- Dean Michael Berris deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2010-12-10 14:09:23
|
Hi Guys,
Today I just finished changing the HTTP Client and HTTP Server
constructor interfaces to use Boost.Parameter. I added tests for the
server constructor interfaces. This basically allows users to write:
using namespace boost::network::http;
server instance(_address="0.0.0.0", _port="8000",
_io_service=my_io_service, _handler=my_handler,
_reuse_address=true);
The supported parameters will be documented accordingly.
Note though that the server constructor interface change is backward
compatible, meaning all previous code that compiled with the server
constructor will still build.
The client constructor interface though is a breaking change.
Basically, what used to be:
http::client instance(http::client::cache_resolved);
Is now:
http::client instance(http::_cache_resolved=true);
This will break code that was written in the old style of the client interface.
Because of this, I'm going to be releasing 0.8.1 which will include a
number of enhancements to the 0.8 implementation, while 0.9 will be a
different "branch". 0.9's client implementation is not source
compatible with code which will be using 0.8 HTTP client interface.
I'm willing to support the 0.8 line for one year, of course subject to
my availability. Commercial support for the 0.8 line is also still
available, contact me for details of that. ;)
The 0.9 release will also introduce external linkage dependencies,
mainly to the externalized parsers for the HTTP client and the
servers.
Thanks everyone and I hope this helps.
--
Dean Michael Berris
deanberris.com
|
|
From: Dean M. B. <mik...@gm...> - 2010-12-09 11:54:13
|
On Thu, Dec 9, 2010 at 3:47 PM, Raindog <ra...@ma...> wrote: > On 12/8/2010 11:37 PM, Dean Michael Berris wrote: >> >> Is this 0.8? The Connection header AFAIK is required in HTTP requests. >> In HTTP/1.1 the Accept-Encoding header tells the server to actually >> just send data encoded a certain way. >> >> In 0.9 this should change. >> >> Please file issues at https://github.com/cpp-netlib/cpp-netlib/issues >> so that we can track this appropriately. >> >> > > I am using the 0.9 branch. > You mean 0.9-devel on my repo right? That's still heavily in flux, but the headers like Connection could be made to be not implicitly defined. As it is right now, the linearize algorithm includes the Connection header if you're not using the keepalive variant of the tags. I have yet to find a way to implement the Asynchronous client that supports the keepalive tag, and re-use connections for HTTP/1.1. HTH -- Dean Michael Berris deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2010-12-09 11:50:50
|
On Thu, Dec 9, 2010 at 3:48 PM, Raindog <ra...@ma...> wrote: > Hello, > > Besides support for the Authorization header, is there any other > support? IE: for Authorization: Basic <b64 encoded username:psw>. I had > to b64 encode my own string and add the header explicitly. Also, support > for digest authentication would be great. > There is no explicit support for Authorization, you really have to add the headers you need to put in your request. The reason the request object is made easy to manipulate is so that these things like Authorization can be written external of the HTTP client. You can write up your own routines to add authorization the requests. These higher level functionality would be nice to have, but they're not yet critical at this point. -- Dean Michael Berris deanberris.com |
|
From: Raindog <ra...@ma...> - 2010-12-09 07:48:27
|
Hello, Besides support for the Authorization header, is there any other support? IE: for Authorization: Basic <b64 encoded username:psw>. I had to b64 encode my own string and add the header explicitly. Also, support for digest authentication would be great. Thanks. |
|
From: Raindog <ra...@ma...> - 2010-12-09 07:48:00
|
On 12/8/2010 11:37 PM, Dean Michael Berris wrote: > On Thu, Dec 9, 2010 at 3:29 PM, Raindog<ra...@ma...> wrote: > > > > I also had an issue with some headers not being able to be removed w/ > > the remove_header directive nor w/ request.remove_header. After some > > digging it turns out that the headers I wanted to remove are hard coded > > to be added. Thingslike: > > > > Connection: Close > > > > and > > > > Accept-Encoding > > > > During my debugging I was trying to recreate some known working HTTP > > requests and the working requests did not have those headers so I wanted > > to remove them but couldn't. Turns out that it did work with them added > > so it wasn't a big deal. > > > > Is this 0.8? The Connection header AFAIK is required in HTTP requests. > In HTTP/1.1 the Accept-Encoding header tells the server to actually > just send data encoded a certain way. > > In 0.9 this should change. > > Please file issues at https://github.com/cpp-netlib/cpp-netlib/issues > so that we can track this appropriately. > > I am using the 0.9 branch. |
|
From: Dean M. B. <mik...@gm...> - 2010-12-09 07:37:58
|
On Thu, Dec 9, 2010 at 3:29 PM, Raindog <ra...@ma...> wrote: > > I also had an issue with some headers not being able to be removed w/ > the remove_header directive nor w/ request.remove_header. After some > digging it turns out that the headers I wanted to remove are hard coded > to be added. Thingslike: > > Connection: Close > > and > > Accept-Encoding > > During my debugging I was trying to recreate some known working HTTP > requests and the working requests did not have those headers so I wanted > to remove them but couldn't. Turns out that it did work with them added > so it wasn't a big deal. > Is this 0.8? The Connection header AFAIK is required in HTTP requests. In HTTP/1.1 the Accept-Encoding header tells the server to actually just send data encoded a certain way. In 0.9 this should change. Please file issues at https://github.com/cpp-netlib/cpp-netlib/issues so that we can track this appropriately. -- Dean Michael Berris deanberris.com |
|
From: Raindog <ra...@ma...> - 2010-12-09 07:30:00
|
On 12/8/2010 9:27 PM, Dean Michael Berris wrote: > On Thu, Dec 9, 2010 at 1:23 PM, Raindog<ra...@ma...> wrote: > > Hello, > > > > I discovered that when using a url such as > > "http://www.example.com:8080", that the HTTP header will only contain: > > > > Host: www.example.com > > > > When it should contain (at least according to Curl and .NET) the > > non-default port after it. such as: > > > > Host: www.example.com:8080 > > > > Interesting. This looks like a bug to me. Can you file it in > https://github.com/cpp-netlib/cpp-netlib/issues ? > > > > > Thanks. > > > > P.S. > > > > I got my file uploader working.. Took a while to test everything because > > of various build issues, but all is done. > > > > Cool, thanks for letting us know! > > I also had an issue with some headers not being able to be removed w/ the remove_header directive nor w/ request.remove_header. After some digging it turns out that the headers I wanted to remove are hard coded to be added. Thingslike: Connection: Close and Accept-Encoding During my debugging I was trying to recreate some known working HTTP requests and the working requests did not have those headers so I wanted to remove them but couldn't. Turns out that it did work with them added so it wasn't a big deal. |
|
From: Dean M. B. <mik...@gm...> - 2010-12-09 05:27:43
|
On Thu, Dec 9, 2010 at 1:23 PM, Raindog <ra...@ma...> wrote: > Hello, > > I discovered that when using a url such as > "http://www.example.com:8080", that the HTTP header will only contain: > > Host: www.example.com > > When it should contain (at least according to Curl and .NET) the > non-default port after it. such as: > > Host: www.example.com:8080 > Interesting. This looks like a bug to me. Can you file it in https://github.com/cpp-netlib/cpp-netlib/issues ? > > Thanks. > > P.S. > > I got my file uploader working.. Took a while to test everything because > of various build issues, but all is done. > Cool, thanks for letting us know! -- Dean Michael Berris deanberris.com |
|
From: Raindog <ra...@ma...> - 2010-12-09 05:24:04
|
Hello, I discovered that when using a url such as "http://www.example.com:8080", that the HTTP header will only contain: Host: www.example.com When it should contain (at least according to Curl and .NET) the non-default port after it. such as: Host: www.example.com:8080 Thanks. P.S. I got my file uploader working.. Took a while to test everything because of various build issues, but all is done. |
|
From: Steve O. <st...@so...> - 2010-12-08 15:00:27
|
----- "Dean Michael Berris" <mik...@gm...> wrote: > Hi Steve, > > On Wed, Dec 8, 2010 at 2:01 PM, Steve Obbayi <st...@so...> > wrote: > > Hi Dean, I am now back, still jet lagged :) > > Great, I hope you had a good vacation. :) > > > Anyway as I was re-familiarizing myself with the code I noticed that > if the user has no > > network and tries to use the http client they get an exception and > the http client quits. > > > > This is by design -- all operations with the synchronous client (like > get, post, put, head, delete_) all throw in case something goes wrong > at any stage of the process (except when reading, an eof causes the > read from the socket to terminate under normal circumstances). > > With the asynchronous client, when you try to use any of the wrappers, > and there was something wrong in the process of getting the response, > it will throw the error that is associated with the error_code > received. > > > I found this out when looking into how to implement the retry on > connection failure feature. > > > > At this point I have not gone further to root out the cause because > a question arose in the process. Should the http client be implemented > with all client connections being made under a try/catch block? Or > should the http client handle these kind of situations internally? Or > is this a bug in the http client. > > > > The client is designed to throw when operations are performed, this is > so that the user of the client can do what they deem necessary in > situations where the client encounters an exceptional condition -- > network errors are considered exceptional conditions. ;) > > > I am using version 0.8 with visual C++ 2010. > > > > You will get this no matter what compiler you use. ;) > > Also, if you are going to work on anything in cpp-netlib, please work > against the latest development branch. Patches submitted against 0.8 > will pretty much be useless with the amount of changes that have > happened between 0.8 and 0.9-devel. :D > > HTH > > -- > Dean Michael Berris > deanberris.com > Okay thanks, for confirming this to me. -- Steve Obbayi SKYPE: sobbayi http://sobbayi.com http://blog.sobbayi.com |
|
From: Dean M. B. <mik...@gm...> - 2010-12-08 06:21:31
|
Hi Steve, On Wed, Dec 8, 2010 at 2:01 PM, Steve Obbayi <st...@so...> wrote: > Hi Dean, I am now back, still jet lagged :) Great, I hope you had a good vacation. :) > Anyway as I was re-familiarizing myself with the code I noticed that if the user has no > network and tries to use the http client they get an exception and the http client quits. > This is by design -- all operations with the synchronous client (like get, post, put, head, delete_) all throw in case something goes wrong at any stage of the process (except when reading, an eof causes the read from the socket to terminate under normal circumstances). With the asynchronous client, when you try to use any of the wrappers, and there was something wrong in the process of getting the response, it will throw the error that is associated with the error_code received. > I found this out when looking into how to implement the retry on connection failure feature. > > At this point I have not gone further to root out the cause because a question arose in the process. Should the http client be implemented with all client connections being made under a try/catch block? Or should the http client handle these kind of situations internally? Or is this a bug in the http client. > The client is designed to throw when operations are performed, this is so that the user of the client can do what they deem necessary in situations where the client encounters an exceptional condition -- network errors are considered exceptional conditions. ;) > I am using version 0.8 with visual C++ 2010. > You will get this no matter what compiler you use. ;) Also, if you are going to work on anything in cpp-netlib, please work against the latest development branch. Patches submitted against 0.8 will pretty much be useless with the amount of changes that have happened between 0.8 and 0.9-devel. :D HTH -- Dean Michael Berris deanberris.com |
|
From: Steve O. <st...@so...> - 2010-12-08 06:03:25
|
Hi Dean, I am now back, still jet lagged :) Anyway as I was re-familiarizing myself with the code I noticed that if the user has no network and tries to use the http client they get an exception and the http client quits. I found this out when looking into how to implement the retry on connection failure feature. At this point I have not gone further to root out the cause because a question arose in the process. Should the http client be implemented with all client connections being made under a try/catch block? Or should the http client handle these kind of situations internally? Or is this a bug in the http client. I am using version 0.8 with visual C++ 2010. Regards Steve Obbayi Software Developer http://www.sobbayi.com |
|
From: Dean M. B. <mik...@gm...> - 2010-12-06 04:34:53
|
On Sat, Dec 4, 2010 at 4:13 AM, Raindog <ra...@ma...> wrote:
> On 12/2/2010 7:24 PM, Dean Michael Berris wrote:
>>
>> Let me know if you need any more information regarding how to make the
>> file contents part of the POST request.
>>
>>
> That would be great if you could. I'm not familiar with HTTP hence why I
> wanted to use your library =). I know that I need a content length and
> some field designating the encoding used, but I don't know how I would
> separate the query string parameters from the actual file being uploaded.
>
That's easy:
http::client c;
http::client::request req("http://example.com/path?p=0&q=1");
http::client::response res = c.post(req, "The contents of the POST body here.");
> Thanks!
You're welcome and I hope that helps.
--
Dean Michael Berris
deanberris.com
|
|
From: Raindog <ra...@ma...> - 2010-12-03 20:14:07
|
On 12/2/2010 7:24 PM, Dean Michael Berris wrote:
> On Fri, Dec 3, 2010 at 11:04 AM, Raindog<ra...@ma...> wrote:
> > "Dean Michael Berris"<mik...@gm...> wrote:
> >>
> >>Actually this isn't an HTTP POST, but rather an HTTP GET request with
> >>the query parameter supplied. This would work for what you intend to
> >>do:
> >>
> >> http::client client;
> >> http::client::request
> >>request("http://www.mysite.com/site.cgi?foo=bar&baz=quid");
> >> http::client::response response = client.get(request);
> >>
> >>HTH
> >>
> >
> > I realize now that after your response that I need also to send a file, I am trying essentially to fill out a web form w/ a file upload element, along with some options, hence why I thought it was a POST. I apologize for not being clear
> >
>
> Re-arranging your response for posterity. ;)
>
> So even in that situation, instead of using 'client.get' you can use
> 'client.post', and then put the file contents as part of the request.
> This isn't easily supported at the moment because the client requires
> that the contents be in a string. If your file is large (multiple
> megabytes) it is an issue and I'm going to address that limitation in
> the coming 0.9 release.
>
> Let me know if you need any more information regarding how to make the
> file contents part of the POST request.
>
>
That would be great if you could. I'm not familiar with HTTP hence why I
wanted to use your library =). I know that I need a content length and
some field designating the encoding used, but I don't know how I would
separate the query string parameters from the actual file being uploaded.
Thanks!
|
|
From: Dean M. B. <mik...@gm...> - 2010-12-03 16:46:11
|
Hi Everyone, To those who are following the development of cpp-netlib (which shall be submitted for review /soon/ as Boost.Netlib), the current state of 0.9-devel and thus what's going to come out officially as 0.9 in a couple of weeks, will not be header-only. Aside from the obvious reason that the compile-times are starting to become unbearable (>10 minutes to build the whole test suite!!) and after noticing that the intended simplicity of the API with tag-metafunction dispatch is limiting the expressiveness of the HTTP client types, the 0.9 release will be the first release that will require an externally linked-in static library. The biggest culprit at the moment has been the implementation of the URI parser that uses Boost.Spirit Qi and >10 rules in the URI parsing grammar. The URI implementation is really declarative and nicely written (thanks go out to Jeroen Habraken for making that happen). The down-side of this has been the compile times: building the simple HTTP client takes close to one minute on the machine I'm using -- and by moving it to an externally-linked static lib, the compile of the same HTTP client is cut down to 10 seconds. Before you ask if I'm using GCC, the answer is no, I'm using Clang when developing so that I get as much speed as I can when doing the edit-rebuild-test cycle. I've written about what I've been doing and what I'll be doing in my three recent articles at C++ Soup. If you want to get more details, please follow the links below. http://cplusplus-soup.com/2010/12/03/cpp-netlib-moving-away-from-header-only/ http://cplusplus-soup.com/2010/12/02/cpp-netlib-demolition-day/ http://cplusplus-soup.com/2010/12/01/cpp-netlib-reducing-compilation-times/ Have a great weekend everyone, please send your qestions/comments/suggestions over either directly to me or through the various mailing lists (Boost-devel, Boost-users, cpp-netlib-devel). -- Dean Michael Berris deanberris.com |
7 messages has been excluded from this view by a project administrator.
