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: Jeroen H. <vex...@gm...> - 2010-01-10 18:44:47
|
On Sun, Jan 10, 2010 at 19:29, Dean Michael Berris <mik...@gm...> wrote: > On Mon, Jan 11, 2010 at 2:26 AM, Jeroen Habraken <vex...@gm...> wrote: >> On Sun, Jan 10, 2010 at 16:28, Dean Michael Berris >> <mik...@gm...> wrote: >>> >>> Sounds like something that would be nice for you to work on. ;) >> >> Sure. >> > > :) > >>> >>> Thanks, you can see the issue here: >>> >>> http://github.com/mikhailberis/cpp-netlib/issues/#issue/1 >>> >> >> FYI, http://github.com/mikhailberis/cpp-netlib/issues#issue/1/comment/107139 >> > > Thanks, I'm applying and pushing the code as soon as the tests all pass. A checkout of the master seems to pass all tests here on my machine, Linux x86 with GCC 4.4.2. > That reminds me, we should be testing this code especially because we ship it. Very much so, though I'm noticing that compiling the tests is quite resource intensive. I've had GCC eat up more than half of my gigabyte of RAM, with the HTTP 1.1 tests taken more than a couple of minutes. > I'll be adding another set of issues regarding this. > > Thanks again Jeroen! > > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-10 18:30:15
|
On Mon, Jan 11, 2010 at 2:26 AM, Jeroen Habraken <vex...@gm...> wrote: > On Sun, Jan 10, 2010 at 16:28, Dean Michael Berris > <mik...@gm...> wrote: >> >> Sounds like something that would be nice for you to work on. ;) > > Sure. > :) >> >> Thanks, you can see the issue here: >> >> http://github.com/mikhailberis/cpp-netlib/issues/#issue/1 >> > > FYI, http://github.com/mikhailberis/cpp-netlib/issues#issue/1/comment/107139 > Thanks, I'm applying and pushing the code as soon as the tests all pass. That reminds me, we should be testing this code especially because we ship it. I'll be adding another set of issues regarding this. Thanks again Jeroen! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-10 18:26:27
|
On Sun, Jan 10, 2010 at 16:28, Dean Michael Berris <mik...@gm...> wrote: > On Sun, Jan 10, 2010 at 10:57 PM, Jeroen Habraken <vex...@gm...> wrote: >> Hi Dean, >> >> On Sun, Jan 10, 2010 at 15:44, Dean Michael Berris >> <mik...@gm...> wrote: >>> >>> Thanks for the report. If you can fix in a patch that would be most helpful too. >>> >>> Actually this was ported in still from pion, and is somewhat >>> "unsupported" yet. I'd prefer this to be re-implemented using >>> Boost.Spirit's Karma. >> >> I'd too love to see this re-implemented using Boost.Spirit's Karma. >> > > Sounds like something that would be nice for you to work on. ;) Sure. >>> >>> Let me file an issue in the cpp-netlib project so that we can track >>> this properly. >>> >>> Have a good day and I hope to see patches for this soon too. ;) >>> >> >> Sure, I'll write one this evening, and attach it to the issue, it's >> rather trivial anyway. >> > > Thanks, you can see the issue here: > > http://github.com/mikhailberis/cpp-netlib/issues/#issue/1 > > > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > FYI, http://github.com/mikhailberis/cpp-netlib/issues#issue/1/comment/107139 Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-10 18:22:39
|
On Mon, Jan 11, 2010 at 2:16 AM, Jeroen Habraken <vex...@gm...> wrote: > > Sorry to be such a pain, but all githell seems to break loose when try > those commands on my fork, I think I'm going to delete it and simply > follow the documentation this time (which I should've the first) :( > No worries, it's all good. :) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-10 18:16:35
|
Hi Dean, On Sun, Jan 10, 2010 at 17:41, Dean Michael Berris <mik...@gm...> wrote: > On Mon, Jan 11, 2010 at 12:32 AM, Jeroen Habraken <vex...@gm...> > wrote: >> >> I've applied a bunch of things from the Fork Queue, and ignored a few >> that failed, which might explain the problem (and would this lead to >> problems in the future, if so, how do I go about fixing it). >> > > One way you can do it is by doing a manual rebase of your fork from your > local repository. You will want to look at git-rebase and git-pull manuals > to get that done. > > What you want to do first is in your master branch, you get the changes from > the 'upstream' branch. Quoting from Github's documentation on Forking > (http://help.github.com/forking/): > >> Pulling in upstream changes >> >> Some time has passed, the upstream repo has changed and you want to update >> your fork before you submit a new patch. There are two ways to do this: >> >> $ git fetch upstream master >> >> $ git merge upstream/master >> >> $ git pull upstream master >> >> git pull is a more direct way, but the merge it performs can be confusing >> if the user doesn’t expect it and a merge conflict results. git fetch will >> also grab all branches, where git pull will only grab the one specified. >> >> If you have local commits that are not in the upstream branch, a normal >> merge will occur. If your local commits are in the upstream branch, a >> fast-forward merge will be done, moving your local branch to the same commit >> as upstream/master. If both repos have edits to the same location in the >> same file, you may run into a merge conflict. Conflicts must be resolved by >> hand and a commit made to complete the merge. >> >> Now that your local branch has been updated, you can commit, push, and >> send a pull request. >> >> You may wish to do the fetch and merge manually, instead of letting >> git-pull do it for you. This can sometimes help avoid headaches caused by >> mysterious merge conflicts. > > (Sorry for the HTML email, I just found it might work better for quoting). > HTH > > Sorry to be such a pain, but all githell seems to break loose when try those commands on my fork, I think I'm going to delete it and simply follow the documentation this time (which I should've the first) :( Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-10 16:42:05
|
On Mon, Jan 11, 2010 at 12:32 AM, Jeroen Habraken <vex...@gm...> wrote: > > I've applied a bunch of things from the Fork Queue, and ignored a few > that failed, which might explain the problem (and would this lead to > problems in the future, if so, how do I go about fixing it). > One way you can do it is by doing a manual rebase of your fork from your local repository. You will want to look at git-rebase and git-pull manuals to get that done. What you want to do first is in your master branch, you get the changes from the 'upstream' branch. Quoting from Github's documentation on Forking ( http://help.github.com/forking/): Pulling in upstream changes > > Some time has passed, the upstream repo has changed and you want to update > your fork before you submit a new patch. There are two ways to do this: > > > $ git fetch upstream master > > $ git merge upstream/master > > > $ git pull upstream master > > git pull is a more direct way, but the merge it performs can be confusing > if the user doesn’t expect it and a merge conflict results. git fetch will > also grab all branches, where git pull will only grab the one specified. > > If you have local commits that are not in the upstream branch, a normal > merge will occur. If your local commits are in the upstream branch, a > fast-forward merge will be done, moving your local branch to the same commit > as upstream/master. If both repos have edits to the same location in the > same file, you may run into a merge conflict. Conflicts must be resolved by > hand and a commit made to complete the merge. > > Now that your local branch has been updated, you can commit, push, and send > a pull request. > > You may wish to do the fetch and merge manually, instead of letting > git-pull do it for you. This can sometimes help avoid headaches caused by > mysterious merge conflicts. > (Sorry for the HTML email, I just found it might work better for quoting). HTH -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-10 16:32:32
|
Hi Dean, On Sun, Jan 10, 2010 at 16:32, Dean Michael Berris <mik...@gm...> wrote: > On Sun, Jan 10, 2010 at 9:43 PM, Jeroen Habraken <vex...@gm...> wrote: >> >> Just found the Fork Queue and I think I've got the basics of github >> figured. I found a bug in the current code on github where I was using >> the Spirit > operator instead of >>, which could lead to exceptions >> being thrown, and made a pull request for that. Next I'll try to merge >> my code with the new parser to the 0.5-devel branch of my fork as I'm >> already working in a 0.5-devel checkout >> > > Cool. > > I've merged it, but then now the problem is it breaks. > > Have you rebased your branch to get the changes I merged into master? > > Because now the implementation fails with wide strings in GCC Linux. > > Let me try to debug locally and push a change to fix it. Please rebase > your branches from master's HEAD if you intend to continue working on > the implementation. :) > > Thanks again and I hope this helps! > > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Cpp-netlib-devel mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel > I've applied a bunch of things from the Fork Queue, and ignored a few that failed, which might explain the problem (and would this lead to problems in the future, if so, how do I go about fixing it). Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-10 15:33:01
|
On Sun, Jan 10, 2010 at 9:43 PM, Jeroen Habraken <vex...@gm...> wrote: > > Just found the Fork Queue and I think I've got the basics of github > figured. I found a bug in the current code on github where I was using > the Spirit > operator instead of >>, which could lead to exceptions > being thrown, and made a pull request for that. Next I'll try to merge > my code with the new parser to the 0.5-devel branch of my fork as I'm > already working in a 0.5-devel checkout > Cool. I've merged it, but then now the problem is it breaks. Have you rebased your branch to get the changes I merged into master? Because now the implementation fails with wide strings in GCC Linux. Let me try to debug locally and push a change to fix it. Please rebase your branches from master's HEAD if you intend to continue working on the implementation. :) Thanks again and I hope this helps! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2010-01-10 15:29:12
|
On Sun, Jan 10, 2010 at 10:57 PM, Jeroen Habraken <vex...@gm...> wrote: > Hi Dean, > > On Sun, Jan 10, 2010 at 15:44, Dean Michael Berris > <mik...@gm...> wrote: >> >> Thanks for the report. If you can fix in a patch that would be most helpful too. >> >> Actually this was ported in still from pion, and is somewhat >> "unsupported" yet. I'd prefer this to be re-implemented using >> Boost.Spirit's Karma. > > I'd too love to see this re-implemented using Boost.Spirit's Karma. > Sounds like something that would be nice for you to work on. ;) >> >> Let me file an issue in the cpp-netlib project so that we can track >> this properly. >> >> Have a good day and I hope to see patches for this soon too. ;) >> > > Sure, I'll write one this evening, and attach it to the issue, it's > rather trivial anyway. > Thanks, you can see the issue here: http://github.com/mikhailberis/cpp-netlib/issues/#issue/1 -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-10 14:57:58
|
Hi Dean, On Sun, Jan 10, 2010 at 15:44, Dean Michael Berris <mik...@gm...> wrote: > Hi Jeroen, > > On Sun, Jan 10, 2010 at 6:52 AM, Jeroen Habraken <vex...@gm...> wrote: >> Hi, >> >> A friend of mine just ran into a corner-case bug in the url_encode >> function in "boost/network/protocol/http/impl/message.ipp". In the >> current 0.5-devel tree it's on line 82, 'sprintf(encode_buf+1, "%2X", >> str[pos]);' to be specific. The format string there should be changed >> to "%02X" to reflect the zero padding (instead of the default space >> padding), as one-character letters such as '\n' are now encoded as '% >> A' (space, A) instead of '%0A' (zero, A). >> > > Thanks for the report. If you can fix in a patch that would be most helpful too. > > Actually this was ported in still from pion, and is somewhat > "unsupported" yet. I'd prefer this to be re-implemented using > Boost.Spirit's Karma. I'd too love to see this re-implemented using Boost.Spirit's Karma. > > Let me file an issue in the cpp-netlib project so that we can track > this properly. > > Have a good day and I hope to see patches for this soon too. ;) > Sure, I'll write one this evening, and attach it to the issue, it's rather trivial anyway. Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-10 14:45:26
|
Hi Jeroen, On Sun, Jan 10, 2010 at 6:52 AM, Jeroen Habraken <vex...@gm...> wrote: > Hi, > > A friend of mine just ran into a corner-case bug in the url_encode > function in "boost/network/protocol/http/impl/message.ipp". In the > current 0.5-devel tree it's on line 82, 'sprintf(encode_buf+1, "%2X", > str[pos]);' to be specific. The format string there should be changed > to "%02X" to reflect the zero padding (instead of the default space > padding), as one-character letters such as '\n' are now encoded as '% > A' (space, A) instead of '%0A' (zero, A). > Thanks for the report. If you can fix in a patch that would be most helpful too. Actually this was ported in still from pion, and is somewhat "unsupported" yet. I'd prefer this to be re-implemented using Boost.Spirit's Karma. Let me file an issue in the cpp-netlib project so that we can track this properly. Have a good day and I hope to see patches for this soon too. ;) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-10 13:51:55
|
Hi Dean, On Sat, Dec 26, 2009 at 05:56, Dean Michael Berris <mik...@gm...> wrote: > Hi Jeroen! > > I apologize for taking a while to respond. I've been away from my > computer for the better part of this Christmas break and I've only > gotten back to my mail now. Please see my response below. > > On Wed, Dec 23, 2009 at 3:12 AM, Jeroen Habraken <vex...@gm...> wrote: >> Hi, >> >> Firstly, thank you Dean for merging my current fork. > > You're welcome! Thanks for the contributions also. :) > >> This however has >> gotten me confused with github, can I still use my current fork to >> continue development (which I suspect will be broken more often, as >> bigger changes are coming), or is it easier to create a new fork. If a >> new fork is easier, what branch should I fork ? >> > > Yes, you can continue to use your fork to continue development. What I > suggest you do is learn how to track a remote branch using git, and > then continue development on 0.5-devel -- or if you prefer, create a > branch on your github fork then do your development from there. > Because you're doing development against the master branch, I'll > integrate your work to my master branch only when you feel it's safe > to integrate to master on your end. > > So the steps would be: > > 1. Create a branch on your fork for your development > 2. Continue development on your branch > 3. Once you're ready to integrate more work in, make sure your master > branch is sync'ed with my master branch > 4. Merge your work from your branch to your master branch > 5. Send me a pull request message and I will integrate to my > fork-integration branch, then integrate to master > > I hope this makes sense. > > Have a great week ahead and I hope you're having a great and restful > holiday season! > > -- > Dean Michael Berris > blog.cplusplus-soup.com | twitter.com/mikhailberis > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > Just found the Fork Queue and I think I've got the basics of github figured. I found a bug in the current code on github where I was using the Spirit > operator instead of >>, which could lead to exceptions being thrown, and made a pull request for that. Next I'll try to merge my code with the new parser to the 0.5-devel branch of my fork as I'm already working in a 0.5-devel checkout Yours, Jeroen |
|
From: Jeroen H. <vex...@gm...> - 2010-01-09 22:52:34
|
Hi, A friend of mine just ran into a corner-case bug in the url_encode function in "boost/network/protocol/http/impl/message.ipp". In the current 0.5-devel tree it's on line 82, 'sprintf(encode_buf+1, "%2X", str[pos]);' to be specific. The format string there should be changed to "%02X" to reflect the zero padding (instead of the default space padding), as one-character letters such as '\n' are now encoded as '% A' (space, A) instead of '%0A' (zero, A). Thanks, Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-09 15:13:53
|
On Sat, Jan 9, 2010 at 11:05 PM, Jeroen Habraken <vex...@gm...> wrote: > On Sat, Jan 9, 2010 at 15:51, Dean Michael Berris > <mik...@gm...> wrote: >> >> Because currently the HTTP URI parses the string at construction time >> (and URI's are immutable anyway), validity checks are as simple as >> returning a boolean. So parse once, validity and data are available >> right away once the object is constructed. > > This is indeed very nice, and should be kept this way, in what I'm > proposing -with the exception of relative URI's, see below- will be > kept that way, mere the place where most of the parsing is done will > change. > Alright. Let's just make sure that it does make sense and doesn't back us into a corner. It's easy to change later on if we find that leaving all the parsing into one parse function is too limiting (or too hard to specialize). >> >> If you are going to allow relative URI's, will that be valid for SMTP >> too? What would be the host? >> > > You're right, adding relative URI support will increase the complexity > of the library more than I initially thought. I'm going to leave it > out, at least for now. Implementing it later shouldn't be a problem if > for any reason we choose to do so. > If there is a good reason for us to support it then I don't have any objection to it. Right now though I don't see it yet so I'm apprehensive still. :) > > Thank you for your thoughts, you might just have prevented me from > overcomplicating things :) > You're welcome. :) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-09 15:05:57
|
On Sat, Jan 9, 2010 at 15:51, Dean Michael Berris <mik...@gm...> wrote: > On Sat, Jan 9, 2010 at 10:21 PM, Jeroen Habraken <vex...@gm...> wrote: >> On Sat, Jan 9, 2010 at 15:01, Dean Michael Berris >> <mik...@gm...> wrote: >>> >>> So how do you build the correct type of URI from a given string? >>> >>> http::uri = "http://www.boost.org"; // should be valid, has URI parts >>> smtp::uri = "http://www.boost.org"; // should be invalid, has different parts >>> >> >> The current generic URI parser will parse the string into the >> following structure: >> struct uri_parts { >> optional<string_type> scheme; >> optional<string_type> user_info >> optional<string_type> host >> optional<uint16_t> port >> string_type path >> optional<string_type> query; >> optional<string_type> fragment; >> } >> >> Note the path here may be defined as empty (thus "") by the RFC, but >> that's different from being omitted. >> >> The first thing to notice is, that even scheme is optional. This way >> we can support relative URI's like "../a/b?foo=bar", and can later >> support resolving an absolute and relative URI. Secondly it might make >> sense to parse user_info into a separate user and password, but this >> is not specified by the RFC. >> > > Personally I don't see why we're going to even support relative URI's > especially since we want to make request generation simple with the > interface. > > Unless you're also going to implement a URI builder interface where > you can generate "correct" URI's programmatically with C++, I don't > see whether supporting relative URI's is going to be a "plus". I may > not be seeing the utility of that especially for a client library. > >> Then in uri::http you can simply check whether the URI scheme exists, >> and is "http" or "https", and check that a host exists (the generic >> parser already guarantees that if it exists it isn't empty), marking >> the URI invalid if these checks fail. >> > > Because currently the HTTP URI parses the string at construction time > (and URI's are immutable anyway), validity checks are as simple as > returning a boolean. So parse once, validity and data are available > right away once the object is constructed. This is indeed very nice, and should be kept this way, in what I'm proposing -with the exception of relative URI's, see below- will be kept that way, mere the place where most of the parsing is done will change. > In what you're proposing, how do you know if it's a valid URI if it's > relative (if you're going to support it) and that it's also using the > correct scheme (if it's omitted)? > >> For the uri::smtp (the format is >> smtp://[username@]host[:port][?options]) you simply check if the >> scheme is "smtp", check that a host exists (and maybe that fragment >> does not) and the path is empty, again marking the URI invalid if >> those demands aren't met. >> > > If you are going to allow relative URI's, will that be valid for SMTP > too? What would be the host? > You're right, adding relative URI support will increase the complexity of the library more than I initially thought. I'm going to leave it out, at least for now. Implementing it later shouldn't be a problem if for any reason we choose to do so. >>> >>> No! Just rebase your current fork, and continue working on that. No >>> need for a new fork! >>> >> >> Ok. >> > > Thanks, looking forward to progress in this front. ;) > > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > Thank you for your thoughts, you might just have prevented me from overcomplicating things :) Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-09 14:51:47
|
On Sat, Jan 9, 2010 at 10:21 PM, Jeroen Habraken <vex...@gm...> wrote: > On Sat, Jan 9, 2010 at 15:01, Dean Michael Berris > <mik...@gm...> wrote: >> >> So how do you build the correct type of URI from a given string? >> >> http::uri = "http://www.boost.org"; // should be valid, has URI parts >> smtp::uri = "http://www.boost.org"; // should be invalid, has different parts >> > > The current generic URI parser will parse the string into the > following structure: > struct uri_parts { > optional<string_type> scheme; > optional<string_type> user_info > optional<string_type> host > optional<uint16_t> port > string_type path > optional<string_type> query; > optional<string_type> fragment; > } > > Note the path here may be defined as empty (thus "") by the RFC, but > that's different from being omitted. > > The first thing to notice is, that even scheme is optional. This way > we can support relative URI's like "../a/b?foo=bar", and can later > support resolving an absolute and relative URI. Secondly it might make > sense to parse user_info into a separate user and password, but this > is not specified by the RFC. > Personally I don't see why we're going to even support relative URI's especially since we want to make request generation simple with the interface. Unless you're also going to implement a URI builder interface where you can generate "correct" URI's programmatically with C++, I don't see whether supporting relative URI's is going to be a "plus". I may not be seeing the utility of that especially for a client library. > Then in uri::http you can simply check whether the URI scheme exists, > and is "http" or "https", and check that a host exists (the generic > parser already guarantees that if it exists it isn't empty), marking > the URI invalid if these checks fail. > Because currently the HTTP URI parses the string at construction time (and URI's are immutable anyway), validity checks are as simple as returning a boolean. So parse once, validity and data are available right away once the object is constructed. In what you're proposing, how do you know if it's a valid URI if it's relative (if you're going to support it) and that it's also using the correct scheme (if it's omitted)? > For the uri::smtp (the format is > smtp://[username@]host[:port][?options]) you simply check if the > scheme is "smtp", check that a host exists (and maybe that fragment > does not) and the path is empty, again marking the URI invalid if > those demands aren't met. > If you are going to allow relative URI's, will that be valid for SMTP too? What would be the host? >> >> No! Just rebase your current fork, and continue working on that. No >> need for a new fork! >> > > Ok. > Thanks, looking forward to progress in this front. ;) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-09 14:21:55
|
On Sat, Jan 9, 2010 at 15:01, Dean Michael Berris <mik...@gm...> wrote: > On Sat, Jan 9, 2010 at 7:58 PM, Jeroen Habraken <vex...@gm...> wrote: >> On Sat, Jan 9, 2010 at 07:59, Dean Michael Berris >> <mik...@gm...> wrote: >>> >>> Okay, I hope you realize that the URI's are not just going to be for >>> HTTP, and that we do want support FTP, SMTP, and other protocols. I >>> don't see how you can do this without the specific parser dispatched >>> by tag. >>> >> >> Yes, what I meant, the new generic parser will actually do this all >> correctly, it now knows the difference between scheme://.. and >> scheme:.. and things like that, thus the new derived objects will only >> have to do checks like "Is the scheme actually 'http'", it won't have >> to do any more specific parsing. >> > > So how do you build the correct type of URI from a given string? > > http::uri = "http://www.boost.org"; // should be valid, has URI parts > smtp::uri = "http://www.boost.org"; // should be invalid, has different parts > The current generic URI parser will parse the string into the following structure: struct uri_parts { optional<string_type> scheme; optional<string_type> user_info optional<string_type> host optional<uint16_t> port string_type path optional<string_type> query; optional<string_type> fragment; } Note the path here may be defined as empty (thus "") by the RFC, but that's different from being omitted. The first thing to notice is, that even scheme is optional. This way we can support relative URI's like "../a/b?foo=bar", and can later support resolving an absolute and relative URI. Secondly it might make sense to parse user_info into a separate user and password, but this is not specified by the RFC. Then in uri::http you can simply check whether the URI scheme exists, and is "http" or "https", and check that a host exists (the generic parser already guarantees that if it exists it isn't empty), marking the URI invalid if these checks fail. For the uri::smtp (the format is smtp://[username@]host[:port][?options]) you simply check if the scheme is "smtp", check that a host exists (and maybe that fragment does not) and the path is empty, again marking the URI invalid if those demands aren't met. > If you don't have the specific parsing (granted that the rules are > very different for either type of URI) I don't see how that could be > done. > >>> >>> I'd like the optional to be exposed too, that's a good idea. I've been >>> thinking about it for a while already and I remember having that as >>> one of the things to change. >>> >>> If you want to change that and the tests to reflect the new interface >>> exposing the optional<>'s then that would be great. :) >>> >> >> Great, I'll change them to reflect that. >> > > Cool. :) > >>>> Jeroen Habraken >>>> >>>> [1] This is currently not committed to git yet, I have still to >>>> properly figure out GitHub, and fork the right branch >>>> >>> >>> Actually, you can continue working on your fork and just ask me to >>> pull when you feel like it's all fine. The fork is basically your >>> branch from master that you maintain. >>> >>> I for one will keep continuing to work with 0.5-devel to implement the >>> other tags and other client types in time for release by the end of >>> the month. If you look at the latest (which you should rebase to) in >>> master, it would show that I've merged the HTTP Server and HTTP 1.1 >>> Client with chunked encoding support (as well as HTTPS). >>> >>> If you're familiar with Git already, then think of your fork as just >>> another repository. Nothing special, you can do whatever you want with >>> your repository. Once you're done making changes in your repository >>> and want to have me integrate your changes to be the "official" >>> release, then you send me a pull request from your master branch -- >>> I'll take care of the merging to cpp-netlib. >>> >>> HTH >>> >>> -- >>> Dean Michael Berris >>> cplusplus-soup.com | twitter.com/deanberris >>> linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com >>> >> >> Great, I think I'll make a new fork, specifically off the 0.5-devel >> branch so things won't have to be merged with the master until >> necessary. >> > > No! Just rebase your current fork, and continue working on that. No > need for a new fork! > Ok. > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-09 14:01:39
|
On Sat, Jan 9, 2010 at 7:58 PM, Jeroen Habraken <vex...@gm...> wrote: > On Sat, Jan 9, 2010 at 07:59, Dean Michael Berris > <mik...@gm...> wrote: >> >> Okay, I hope you realize that the URI's are not just going to be for >> HTTP, and that we do want support FTP, SMTP, and other protocols. I >> don't see how you can do this without the specific parser dispatched >> by tag. >> > > Yes, what I meant, the new generic parser will actually do this all > correctly, it now knows the difference between scheme://.. and > scheme:.. and things like that, thus the new derived objects will only > have to do checks like "Is the scheme actually 'http'", it won't have > to do any more specific parsing. > So how do you build the correct type of URI from a given string? http::uri = "http://www.boost.org"; // should be valid, has URI parts smtp::uri = "http://www.boost.org"; // should be invalid, has different parts If you don't have the specific parsing (granted that the rules are very different for either type of URI) I don't see how that could be done. >> >> I'd like the optional to be exposed too, that's a good idea. I've been >> thinking about it for a while already and I remember having that as >> one of the things to change. >> >> If you want to change that and the tests to reflect the new interface >> exposing the optional<>'s then that would be great. :) >> > > Great, I'll change them to reflect that. > Cool. :) >>> Jeroen Habraken >>> >>> [1] This is currently not committed to git yet, I have still to >>> properly figure out GitHub, and fork the right branch >>> >> >> Actually, you can continue working on your fork and just ask me to >> pull when you feel like it's all fine. The fork is basically your >> branch from master that you maintain. >> >> I for one will keep continuing to work with 0.5-devel to implement the >> other tags and other client types in time for release by the end of >> the month. If you look at the latest (which you should rebase to) in >> master, it would show that I've merged the HTTP Server and HTTP 1.1 >> Client with chunked encoding support (as well as HTTPS). >> >> If you're familiar with Git already, then think of your fork as just >> another repository. Nothing special, you can do whatever you want with >> your repository. Once you're done making changes in your repository >> and want to have me integrate your changes to be the "official" >> release, then you send me a pull request from your master branch -- >> I'll take care of the merging to cpp-netlib. >> >> HTH >> >> -- >> Dean Michael Berris >> cplusplus-soup.com | twitter.com/deanberris >> linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com >> > > Great, I think I'll make a new fork, specifically off the 0.5-devel > branch so things won't have to be merged with the master until > necessary. > No! Just rebase your current fork, and continue working on that. No need for a new fork! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-09 11:59:01
|
On Sat, Jan 9, 2010 at 07:59, Dean Michael Berris <mik...@gm...> wrote: > On Sat, Jan 9, 2010 at 8:16 AM, Jeroen Habraken <vex...@gm...> wrote: >> Hi guys, >> >> It's been a while since you've heard from me, and first of all -though >> somewhat late- a Happy New Year. > > Happy New Year to you too! :) > >> I've been reading up on the RFC and >> Spirit documentation (Spirit is pure genius by the way). I'm now >> working towards a full RFC compatible parser[1]. In doing so I've >> found the newer RFC3986 is much more of a pleasure to work with, and >> the specific HTTP parser isn't needed any more. >> > > Okay, I hope you realize that the URI's are not just going to be for > HTTP, and that we do want support FTP, SMTP, and other protocols. I > don't see how you can do this without the specific parser dispatched > by tag. > Yes, what I meant, the new generic parser will actually do this all correctly, it now knows the difference between scheme://.. and scheme:.. and things like that, thus the new derived objects will only have to do checks like "Is the scheme actually 'http'", it won't have to do any more specific parsing. >> I've noticed a couple of things though, and I'm uncertain on how to >> solve them. First of all, ports, there is the difference between the >> parsed port, and the actual port to use when connecting, based on >> default ports. The google-url has a port and EffectiveIntPort >> function, but this information is also needed when normalising the >> URI. Secondly, the parser knows the difference between no fragment, >> and an empty fragment, but the current API does not expose this. Would >> exposing the optional<string_type>'s be a solution? >> > > I'd like the optional to be exposed too, that's a good idea. I've been > thinking about it for a while already and I remember having that as > one of the things to change. > > If you want to change that and the tests to reflect the new interface > exposing the optional<>'s then that would be great. :) > Great, I'll change them to reflect that. >> Jeroen Habraken >> >> [1] This is currently not committed to git yet, I have still to >> properly figure out GitHub, and fork the right branch >> > > Actually, you can continue working on your fork and just ask me to > pull when you feel like it's all fine. The fork is basically your > branch from master that you maintain. > > I for one will keep continuing to work with 0.5-devel to implement the > other tags and other client types in time for release by the end of > the month. If you look at the latest (which you should rebase to) in > master, it would show that I've merged the HTTP Server and HTTP 1.1 > Client with chunked encoding support (as well as HTTPS). > > If you're familiar with Git already, then think of your fork as just > another repository. Nothing special, you can do whatever you want with > your repository. Once you're done making changes in your repository > and want to have me integrate your changes to be the "official" > release, then you send me a pull request from your master branch -- > I'll take care of the merging to cpp-netlib. > > HTH > > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > Great, I think I'll make a new fork, specifically off the 0.5-devel branch so things won't have to be merged with the master until necessary. Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-09 07:00:17
|
On Sat, Jan 9, 2010 at 8:16 AM, Jeroen Habraken <vex...@gm...> wrote: > Hi guys, > > It's been a while since you've heard from me, and first of all -though > somewhat late- a Happy New Year. Happy New Year to you too! :) > I've been reading up on the RFC and > Spirit documentation (Spirit is pure genius by the way). I'm now > working towards a full RFC compatible parser[1]. In doing so I've > found the newer RFC3986 is much more of a pleasure to work with, and > the specific HTTP parser isn't needed any more. > Okay, I hope you realize that the URI's are not just going to be for HTTP, and that we do want support FTP, SMTP, and other protocols. I don't see how you can do this without the specific parser dispatched by tag. > I've noticed a couple of things though, and I'm uncertain on how to > solve them. First of all, ports, there is the difference between the > parsed port, and the actual port to use when connecting, based on > default ports. The google-url has a port and EffectiveIntPort > function, but this information is also needed when normalising the > URI. Secondly, the parser knows the difference between no fragment, > and an empty fragment, but the current API does not expose this. Would > exposing the optional<string_type>'s be a solution? > I'd like the optional to be exposed too, that's a good idea. I've been thinking about it for a while already and I remember having that as one of the things to change. If you want to change that and the tests to reflect the new interface exposing the optional<>'s then that would be great. :) > Jeroen Habraken > > [1] This is currently not committed to git yet, I have still to > properly figure out GitHub, and fork the right branch > Actually, you can continue working on your fork and just ask me to pull when you feel like it's all fine. The fork is basically your branch from master that you maintain. I for one will keep continuing to work with 0.5-devel to implement the other tags and other client types in time for release by the end of the month. If you look at the latest (which you should rebase to) in master, it would show that I've merged the HTTP Server and HTTP 1.1 Client with chunked encoding support (as well as HTTPS). If you're familiar with Git already, then think of your fork as just another repository. Nothing special, you can do whatever you want with your repository. Once you're done making changes in your repository and want to have me integrate your changes to be the "official" release, then you send me a pull request from your master branch -- I'll take care of the merging to cpp-netlib. HTH -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-09 00:47:56
|
Hi guys, It's been a while since you've heard from me, and first of all -though somewhat late- a Happy New Year. I've been reading up on the RFC and Spirit documentation (Spirit is pure genius by the way). I'm now working towards a full RFC compatible parser[1]. In doing so I've found the newer RFC3986 is much more of a pleasure to work with, and the specific HTTP parser isn't needed any more. I've noticed a couple of things though, and I'm uncertain on how to solve them. First of all, ports, there is the difference between the parsed port, and the actual port to use when connecting, based on default ports. The google-url has a port and EffectiveIntPort function, but this information is also needed when normalising the URI. Secondly, the parser knows the difference between no fragment, and an empty fragment, but the current API does not expose this. Would exposing the optional<string_type>'s be a solution? Jeroen Habraken [1] This is currently not committed to git yet, I have still to properly figure out GitHub, and fork the right branch |
|
From: Dean M. B. <mik...@gm...> - 2010-01-08 16:40:16
|
On Tue, Jan 5, 2010 at 1:37 AM, Dean Michael Berris <mik...@gm...> wrote: > > Right now there are two outstanding failures in the tests -- I'm going > to get back to making sure they pass before merging 0.5-devel into > master. > They're fixed now and I've merged a snapshot version of 0.5-devel into master too. I'll continue working on 0.5-devel to implement the asynchronous stuff and then start thinking about streaming too. All tests are green at the moment so please feel free to test on different platforms -- right now I only have access to Linux 64-bit and GCC 4.4.1. Have a good day everyone and I hope this helps! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2010-01-04 17:37:28
|
First, Happy New Year Everyone! Next, the latest push I did to the Git repository just implements (in a hackish not-so-clean way) HTTP 1.1 Chunked Transfer-Encoding support [0]. So now we can really start testing with HTTP 1.1 locally and over the web. Right now there are two outstanding failures in the tests -- I'm going to get back to making sure they pass before merging 0.5-devel into master. At the moment, testing help would be very much appreciated. At this time we're on track for supporting HTTP 1.1 in 0.5 and releasing 0.5 by the end of the month. Thanks to everyone's support! Questions, comments, suggestions, are most welcome. Have a good day everyone and I hope this helps! Links: - [0] http://github.com/mikhailberis/cpp-netlib/commit/0aed5d18cc75dc3fce474478f61ae67bb40f7797 -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2009-12-29 10:25:48
|
Hi Guys! I hope everyone had a good holiday season -- it's still not yet over though -- and I'm having some trouble that I need some help with in Python. Here it goes: As you all already know there's already an HTTPS client in the 0.5-devel branch. I've tried so hard to get the Python server up and running supporting HTTPS but unfortunately the server always fails for POST requests. I am not sure whether it's something that the current implementation is not inherently able to handle, or whether the client is having problems creating POST requests in non-HTTPS mode. Is there anyone with enough experience with Python and WSGI able to come up with a simple service that would acknowledge POST/PUT requests using the WSGI interface? This testing block is causing me to spend too much time with a language and framework that I'm not very familiar with -- and I'm hoping someone else in the list is willing to help out. Thanks in advance and I hope this helps! -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2009-12-26 04:56:42
|
Hi Jeroen! I apologize for taking a while to respond. I've been away from my computer for the better part of this Christmas break and I've only gotten back to my mail now. Please see my response below. On Wed, Dec 23, 2009 at 3:12 AM, Jeroen Habraken <vex...@gm...> wrote: > Hi, > > Firstly, thank you Dean for merging my current fork. You're welcome! Thanks for the contributions also. :) > This however has > gotten me confused with github, can I still use my current fork to > continue development (which I suspect will be broken more often, as > bigger changes are coming), or is it easier to create a new fork. If a > new fork is easier, what branch should I fork ? > Yes, you can continue to use your fork to continue development. What I suggest you do is learn how to track a remote branch using git, and then continue development on 0.5-devel -- or if you prefer, create a branch on your github fork then do your development from there. Because you're doing development against the master branch, I'll integrate your work to my master branch only when you feel it's safe to integrate to master on your end. So the steps would be: 1. Create a branch on your fork for your development 2. Continue development on your branch 3. Once you're ready to integrate more work in, make sure your master branch is sync'ed with my master branch 4. Merge your work from your branch to your master branch 5. Send me a pull request message and I will integrate to my fork-integration branch, then integrate to master I hope this makes sense. Have a great week ahead and I hope you're having a great and restful holiday season! -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
7 messages has been excluded from this view by a project administrator.
