Menu
▾
▴
cpp-netlib-devel
|
From: Michael D. <mi...@mi...> - 2007-12-11 02:40:51
|
Dean and I have been talking on the boost development list about ways to integrate Pion code into the current cpp-netlib structure. Seemed like a good idea to move that discussion over to this list instead. I think that the best starting point would be to focus on merging over Pion's HTTPParser class: http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_parser_8hpp-source.html http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_parser_8cpp-source.html It's an incremental parser that can be used for both 1.0 and 1.1, and also for both requests and responses. It seems like you could just reformat & rename it for boost's style standards, remove the logging support, and use cpp-netlib's http::request and http::response classes in favor of Pion's HTTPRequest and HTTPResponse (so long as they support the same functionality). FYI: one major thing currently missing in the parser is being able to parse HTTP/1.1 chunks. This is supported in the "Writer" classes (see below) but not in our underlying parsing code. Someone is working on this right now actually, and we will probably have it in there by the end of the week. To see an example of how we use it to parse a request or response message, check out the HTTPMessage::receive() implementation: http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_message_8cpp-source.html Or for an asynchronous usage example, check out the HTTPReader class: http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_reader_8hpp-source.html http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_reader_8cpp-source.html Or the HTTPRequestReader and HTTPResponseReader classes: http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_request_reader_8hpp-source.html http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_response_reader_8hpp-source.html If you're interested in Pion's asynchronous sending code, just replace "Reader" in any of these names with "Writer": http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_writer_8hpp-source.html http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_writer_8cpp-source.html http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_request_writer_8hpp-source.html http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_response_writer_8hpp-source.html I'd really love to get more involve and work directly on converting this code over, but honestly I'm not all that great with templates and doing things right for a header-only approach. Your basic_message code definitely looks cooler and more extensible but I'm having a little trouble fully grok'ing it. Plus, I figure you would probably do things differently than I =) In any case, if we could figure out how to merge this functionality over I'd be happy to switch over to using cpp-netlib in Pion instead of our own message-like classes. Take care, -Mike |
|
From: Alex O. <al...@gm...> - 2007-12-11 08:14:29
|
Hello all
Not directly related to the pion http parser
i had looked into protocol/http/impl/request.hpp and had seen, that it
include URI parser. i think, that it better to implement URI parser in
their own namespace, as it could be used not only in http parsing, but
also in other places.
Also, may be it will be useful during implementation - may be not hard
code "HTTP" protocol name in parser, but specify it as template
parameter? I suggest this, as some other protocols (such as ICAP), use
the same structure as HTTP, but different protocol name
P.S. i has almost working http request/response parsers, but i has
some problems with mixing boost::spirit + std::multimap.
I use following structures to hold information about request/response
(and corresponding parsers):
struct Version {
std::string protocol;
unsigned int major;
unsigned int minor;
};
struct Common {
Version version;
typedef std::multimap<std::string,std::string> headers_t;
headers_t headers;
std::string body; // may be will replaced with vector<char>
} ;
struct Request : public Common {
URI url;
std::string command;
} ;
struct Response : public Common {
std::string textStatus;
uint16_t intStatus;
} ;
--
With best wishes, Alex Ott, MBA
http://alexott.blogspot.com/
http://alexott-ru.blogspot.com/
http://content-filtering.blogspot.com/
http://xtalk.msk.su/~ott/
|
|
From: Dean M. B. <mik...@gm...> - 2007-12-11 08:22:46
|
Hi Alex,
On Dec 11, 2007 4:14 PM, Alex Ott <al...@gm...> wrote:
>
> i had looked into protocol/http/impl/request.hpp and had seen, that it
> include URI parser. i think, that it better to implement URI parser in
> their own namespace, as it could be used not only in http parsing, but
> also in other places.
Yup, I agree. I intend to refactor those out later -- but that would
mean there would be tons of tests just to make sure that the parser is
correct. That sounds like a lot of work, but if you'd like to try that
out, please be my guest. :)
> Also, may be it will be useful during implementation - may be not hard
> code "HTTP" protocol name in parser, but specify it as template
> parameter? I suggest this, as some other protocols (such as ICAP), use
> the same structure as HTTP, but different protocol name
>
This makes sense.
Please add a task in the tracker -- Glyn, do you have an idea how to
best use the Sourceforge Trackers?
> P.S. i has almost working http request/response parsers, but i has
> some problems with mixing boost::spirit + std::multimap.
> I use following structures to hold information about request/response
> (and corresponding parsers):
>
> struct Version {
> std::string protocol;
> unsigned int major;
> unsigned int minor;
> };
>
> struct Common {
> Version version;
> typedef std::multimap<std::string,std::string> headers_t;
> headers_t headers;
> std::string body; // may be will replaced with vector<char>
> } ;
> struct Request : public Common {
> URI url;
> std::string command;
> } ;
> struct Response : public Common {
> std::string textStatus;
> uint16_t intStatus;
> } ;
>
I'm not sure what you're trying to accomplish though, so it's hard to
comment. I've found out that with Boost.Spirit, it's usually best that
you use semantic actions built with Phoenix. I'm not sure if there
have been major changes with Phoenix the past few months, and having
seen Boost.Spirit being release-ready in Boost Trunk, it would be a
good idea to use those instead.
Having said that, we should be updating the sources that require
Fusion -- there have been breaking changes with the directory
structure since we last tested the code, but unfortunately I don't
have time yet to get to those.
--
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mik...@gm...]
[+63 928 7291459]
[+1 408 4049523]
|
|
From: Alex O. <al...@gm...> - 2007-12-11 08:27:23
|
Hi On Dec 11, 2007 9:22 AM, Dean Michael Berris <mik...@gm...> wrote: > Hi Alex, > > On Dec 11, 2007 4:14 PM, Alex Ott <al...@gm...> wrote: > > > > i had looked into protocol/http/impl/request.hpp and had seen, that it > > include URI parser. i think, that it better to implement URI parser in > > their own namespace, as it could be used not only in http parsing, but > > also in other places. > > Yup, I agree. I intend to refactor those out later -- but that would > mean there would be tons of tests just to make sure that the parser is > correct. That sounds like a lot of work, but if you'd like to try that > out, please be my guest. :) Yes, i for a long time looking for this project in SVN > > Also, may be it will be useful during implementation - may be not hard > > code "HTTP" protocol name in parser, but specify it as template > > parameter? I suggest this, as some other protocols (such as ICAP), use > > the same structure as HTTP, but different protocol name > > > > This makes sense. > > Please add a task in the tracker -- Glyn, do you have an idea how to > best use the Sourceforge Trackers? Ok, add > > P.S. i has almost working http request/response parsers, but i has > > some problems with mixing boost::spirit + std::multimap. > > I use following structures to hold information about request/response > > (and corresponding parsers): > I'm not sure what you're trying to accomplish though, so it's hard to > comment. I've found out that with Boost.Spirit, it's usually best that > you use semantic actions built with Phoenix. I'm not sure if there > have been major changes with Phoenix the past few months, and having > seen Boost.Spirit being release-ready in Boost Trunk, it would be a > good idea to use those instead. > > Having said that, we should be updating the sources that require > Fusion -- there have been breaking changes with the directory > structure since we last tested the code, but unfortunately I don't > have time yet to get to those. Ok, i switch to fusion & phoenix, and try to help you in implementing http parsers - i'm currently writer several projects, that require http parsing, so we'll has good test cases ;-) -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://alexott-ru.blogspot.com/ http://content-filtering.blogspot.com/ http://xtalk.msk.su/~ott/ |
|
From: Dean M. B. <mik...@gm...> - 2007-12-11 08:26:11
|
Hi Mike! On Dec 11, 2007 10:40 AM, Michael Dickey <mi...@mi...> wrote: > Dean and I have been talking on the boost development list about ways > to integrate Pion code into the current cpp-netlib structure. Seemed > like a good idea to move that discussion over to this list instead. > I agree, though I'd also like to have other people in the Boost mailing list involved somehow. I like the input that we get there, and I'm thankful that the discussion has brought out interesting insights from people in the list. :) > I think that the best starting point would be to focus on merging over > Pion's HTTPParser class: > > http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_parser_8hpp-source.html > http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_parser_8cpp-source.html > > It's an incremental parser that can be used for both 1.0 and 1.1, and > also for both requests and responses. It seems like you could just > reformat & rename it for boost's style standards, remove the logging > support, and use cpp-netlib's http::request and http::response classes > in favor of Pion's HTTPRequest and HTTPResponse (so long as they > support the same functionality). > > FYI: one major thing currently missing in the parser is being able to > parse HTTP/1.1 chunks. This is supported in the "Writer" classes (see > below) but not in our underlying parsing code. Someone is working on > this right now actually, and we will probably have it in there by the > end of the week. > > To see an example of how we use it to parse a request or response > message, check out the HTTPMessage::receive() implementation: > > http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_message_8cpp-source.html > > Or for an asynchronous usage example, check out the HTTPReader class: > > http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_reader_8hpp-source.html > http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_reader_8cpp-source.html > > Or the HTTPRequestReader and HTTPResponseReader classes: > > http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_request_reader_8hpp-source.html > http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_response_reader_8hpp-source.html > > If you're interested in Pion's asynchronous sending code, just replace > "Reader" in any of these names with "Writer": > > http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_writer_8hpp-source.html > http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_writer_8cpp-source.html > http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_request_writer_8hpp-source.html > http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_response_writer_8hpp-source.html > > I'd really love to get more involve and work directly on converting > this code over, but honestly I'm not all that great with templates and > doing things right for a header-only approach. Your basic_message > code definitely looks cooler and more extensible but I'm having a > little trouble fully grok'ing it. Plus, I figure you would probably > do things differently than I =) > I'll go ahead and schedule this for later -- we should really be using the Sourceforge tracker for these "TODO's" . > In any case, if we could figure out how to merge this functionality > over I'd be happy to switch over to using cpp-netlib in Pion instead > of our own message-like classes. > Sweet! That sounds like good motivation for me to actually write more documentation, try porting your better parser, and see how else we can improve on decoupling the logging/networking/etc. from the actual parsing. Just a question: why shouldn't we be using Boost.Spirit for this sort of thing? -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mik...@gm...] [+63 928 7291459] [+1 408 4049523] |
|
From: Glyn M. <gly...@gm...> - 2007-12-11 08:34:00
|
Hi, Please add a task in the tracker -- Glyn, do you have an idea how to > best use the Sourceforge Trackers? Yes, I see the feature has already been added but I'll configure the tracker a bit better to make it easier for us to use. G |
|
From: Dean M. B. <mik...@gm...> - 2007-12-11 08:34:46
|
On Dec 11, 2007 4:33 PM, Glyn Matthews <gly...@gm...> wrote: > > Hi, > > > Please add a task in the tracker -- Glyn, do you have an idea how to > > best use the Sourceforge Trackers? > > Yes, I see the feature has already been added but I'll configure the tracker > a bit better to make it easier for us to use. > G > Thanks Glyn! -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mik...@gm...] [+63 928 7291459] [+1 408 4049523] |
|
From: Michael D. <mi...@mi...> - 2007-12-11 18:02:27
|
On Dec 11, 2007, at 12:26 AM, Dean Michael Berris wrote: > Hi Mike! > > On Dec 11, 2007 10:40 AM, Michael Dickey <mi...@mi...> wrote: >> Dean and I have been talking on the boost development list about ways >> to integrate Pion code into the current cpp-netlib structure. Seemed >> like a good idea to move that discussion over to this list instead. > > I agree, though I'd also like to have other people in the Boost > mailing list involved somehow. I like the input that we get there, and > I'm thankful that the discussion has brought out interesting insights > from people in the list. :) I'm new to the Boost list, so I just wasn't sure about overwhelming it messages on this topic -- in particular as we get more into implementation details. I can re-post my message there though if you think others would be interested in chiming in. ... >> In any case, if we could figure out how to merge this functionality >> over I'd be happy to switch over to using cpp-netlib in Pion instead >> of our own message-like classes. >> > > Sweet! That sounds like good motivation for me to actually write more > documentation, try porting your better parser, and see how else we can > improve on decoupling the logging/networking/etc. from the actual > parsing. Great, feel free to use as much or little of it as you like! =) And of course, let me know if you have any questions.. > Just a question: why shouldn't we be using Boost.Spirit for this > sort of thing? The main reason I didn't use it is that I'm not familiar with Boost.Spirit, and the parsing code was original based on Chris' http_server examples in ASIO (which do not use Spirit). I got the impression from reading through the Spirit pages that it does incur a performance penalty, and I wanted to make everything in Pion as fast as possible. Also, I wasn't clear if Spirit could handle the incremental processing needs. Namely, the parser needs to be able to consume as few as 1 byte at a time to make it asynchronous, low- memory and HTTP/1.1 compatible. Take care, -Mike |
|
From: Dean M. B. <mik...@gm...> - 2007-12-12 12:34:32
|
Hi Mike! Sorry this took a while, been swamped with work lately. On Dec 12, 2007 2:02 AM, Michael Dickey <mi...@mi...> wrote: > On Dec 11, 2007, at 12:26 AM, Dean Michael Berris wrote: > > > Hi Mike! > > > > On Dec 11, 2007 10:40 AM, Michael Dickey <mi...@mi...> wrote: > >> Dean and I have been talking on the boost development list about ways > >> to integrate Pion code into the current cpp-netlib structure. Seemed > >> like a good idea to move that discussion over to this list instead. > > > > I agree, though I'd also like to have other people in the Boost > > mailing list involved somehow. I like the input that we get there, and > > I'm thankful that the discussion has brought out interesting insights > > from people in the list. :) > > I'm new to the Boost list, so I just wasn't sure about overwhelming it > messages on this topic -- in particular as we get more into > implementation details. I can re-post my message there though if you > think others would be interested in chiming in. > Now that I think about it, it would really make sense once we get the HTTP parsing and somehow implement it and make it work with the basic_message<> type. This should open up the discussion to more possibilities. It's really just a lot of work, and I currently do not have the time to get to it yet. > ... > >> In any case, if we could figure out how to merge this functionality > >> over I'd be happy to switch over to using cpp-netlib in Pion instead > >> of our own message-like classes. > >> > > > > Sweet! That sounds like good motivation for me to actually write more > > documentation, try porting your better parser, and see how else we can > > improve on decoupling the logging/networking/etc. from the actual > > parsing. > > Great, feel free to use as much or little of it as you like! =) > > And of course, let me know if you have any questions.. > Thanks! Will do. :) > > Just a question: why shouldn't we be using Boost.Spirit for this > > sort of thing? > > The main reason I didn't use it is that I'm not familiar with > Boost.Spirit, and the parsing code was original based on Chris' > http_server examples in ASIO (which do not use Spirit). > > I got the impression from reading through the Spirit pages that it > does incur a performance penalty, and I wanted to make everything in > Pion as fast as possible. Also, I wasn't clear if Spirit could handle > the incremental processing needs. Namely, the parser needs to be able > to consume as few as 1 byte at a time to make it asynchronous, low- > memory and HTTP/1.1 compatible. > Now that you mention it, I think using Spirit in this context (incremental parsing, DFA style) might not make much sense. I'll try reading up on Boost.Statechart which might be a better fit (maybe better than a hand-rolled switch() which becomes unwieldy most times) or perhaps Expressive for some pattern matching/parsing. Though from the looks of it, we have a lot of stuff we can work with already. Now it's just a matter of getting to it. ;-) Again, thanks Mike and have a great day! -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mik...@gm...] [+63 928 7291459] [+1 408 4049523] |
|
From: Michael D. <mi...@mi...> - 2007-12-12 22:19:26
|
Update: Mignon just committed into trunk (r339) support for parsing chunks, either in request or response content, for our synchronous HTTPMessage::receive() calls and also for the asynchronous HTTP*Reader classes. Take care, -Mike On Dec 10, 2007, at 6:40 PM, Michael Dickey wrote: > Dean and I have been talking on the boost development list about > ways to integrate Pion code into the current cpp-netlib structure. > Seemed like a good idea to move that discussion over to this list > instead. > > I think that the best starting point would be to focus on merging > over Pion's HTTPParser class: > > http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_parser_8hpp-source.html > http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_parser_8cpp-source.html > > It's an incremental parser that can be used for both 1.0 and 1.1, > and also for both requests and responses. It seems like you could > just reformat & rename it for boost's style standards, remove the > logging support, and use cpp-netlib's http::request and > http::response classes in favor of Pion's HTTPRequest and > HTTPResponse (so long as they support the same functionality). > > FYI: one major thing currently missing in the parser is being able > to parse HTTP/1.1 chunks. This is supported in the "Writer" classes > (see below) but not in our underlying parsing code. Someone is > working on this right now actually, and we will probably have it in > there by the end of the week. > ... |
|
From: Alex O. <al...@gm...> - 2007-12-13 10:13:59
|
Hello all
On Dec 11, 2007 9:22 AM, Dean Michael Berris <mik...@gm...> wrote:
> Hi Alex,
>
> On Dec 11, 2007 4:14 PM, Alex Ott <al...@gm...> wrote:
> >
> > i had looked into protocol/http/impl/request.hpp and had seen, that it
> > include URI parser. i think, that it better to implement URI parser in
> > their own namespace, as it could be used not only in http parsing, but
> > also in other places.
>
> Yup, I agree. I intend to refactor those out later -- but that would
> mean there would be tons of tests just to make sure that the parser is
> correct. That sounds like a lot of work, but if you'd like to try that
> out, please be my guest. :)
Here is small patch, that could be useful - it should capture
userinfo, that sometimes used in URI's.
I'm thinking about rewriting URI part to complete matching to rfc 3986
Index: request.hpp
===================================================================
--- request.hpp (revision 28)
+++ request.hpp (working copy)
@@ -30,6 +30,7 @@
class basic_request {
struct tags {
struct protocol { };
+ struct userinfo { };
struct host { };
struct port { };
struct path { };
@@ -39,6 +40,7 @@
typedef fusion::map<
fusion::pair<typename tags::protocol,typename tag::str_type>,
+ fusion::pair<typename tags::userinfo,typename tag::str_type>,
fusion::pair<typename tags::host,typename tag::str_type>,
fusion::pair<typename tags::port,unsigned int>,
fusion::pair<typename tags::path,typename tag::str_type>,
@@ -63,6 +65,14 @@
= construct_<typename tag::str_type>(arg1, arg2)
]
>> str_p("://")
+ >> !(
+ >> (*(alnum_p | '.' | '-' | '_'| '~'|'!' | '$' |
'&' | '\'' | '('| ')'
+ | '*' | '+' | ',' |
';' | '='))[
+
var(fusion::at_key<typename tags::userinfo>(uri_parts))
+ = construct_<typename tag::str_type>(arg1, arg2)
+ ]
+ >> ch_p('@')
+ )
>> (+(alnum_p | '.' | '-' | '_'))[
var(fusion::at_key<typename tags::host>(uri_parts))
= construct_<typename tag::str_type>(arg1, arg2)
--
With best wishes, Alex Ott, MBA
http://alexott.blogspot.com/
http://alexott-ru.blogspot.com/
http://content-filtering.blogspot.com/
http://xtalk.msk.su/~ott/
|
|
From: Dean M. B. <mik...@gm...> - 2007-12-13 10:24:09
|
Hi Alex, On Dec 13, 2007 6:13 PM, Alex Ott <al...@gm...> wrote: > Hello all > > On Dec 11, 2007 9:22 AM, Dean Michael Berris <mik...@gm...> wrote: > > Hi Alex, > > > > On Dec 11, 2007 4:14 PM, Alex Ott <al...@gm...> wrote: > > > > > > i had looked into protocol/http/impl/request.hpp and had seen, that it > > > include URI parser. i think, that it better to implement URI parser in > > > their own namespace, as it could be used not only in http parsing, but > > > also in other places. > > > > Yup, I agree. I intend to refactor those out later -- but that would > > mean there would be tons of tests just to make sure that the parser is > > correct. That sounds like a lot of work, but if you'd like to try that > > out, please be my guest. :) > > Here is small patch, that could be useful - it should capture > userinfo, that sometimes used in URI's. > I'm thinking about rewriting URI part to complete matching to rfc 3986 > Please write tests to cover this addition. If you can, please write tests to make sure that the parsing is compliant with the rfc as well. Thank you very much. -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mik...@gm...] [+63 928 7291459] [+1 408 4049523] |
|
From: Alex O. <al...@gm...> - 2007-12-13 11:22:13
|
Hello Ok, i'll try to write complete suite, and then send it to list. I'm currently thinking about relations between generic URI's and http URL's (and other protocols) - for example, setting default ports, etc. On Dec 13, 2007 11:24 AM, Dean Michael Berris <mik...@gm...> wrote: > Hi Alex, > > On Dec 13, 2007 6:13 PM, Alex Ott <al...@gm...> wrote: > > Hello all > > > > On Dec 11, 2007 9:22 AM, Dean Michael Berris <mik...@gm...> wrote: > > > Hi Alex, > > > > > > On Dec 11, 2007 4:14 PM, Alex Ott <al...@gm...> wrote: > > > > > > > > i had looked into protocol/http/impl/request.hpp and had seen, that it > > > > include URI parser. i think, that it better to implement URI parser in > > > > their own namespace, as it could be used not only in http parsing, but > > > > also in other places. > > > > > > Yup, I agree. I intend to refactor those out later -- but that would > > > mean there would be tons of tests just to make sure that the parser is > > > correct. That sounds like a lot of work, but if you'd like to try that > > > out, please be my guest. :) > > > > Here is small patch, that could be useful - it should capture > > userinfo, that sometimes used in URI's. > > I'm thinking about rewriting URI part to complete matching to rfc 3986 > > > > Please write tests to cover this addition. > > If you can, please write tests to make sure that the parsing is > compliant with the rfc as well. > > Thank you very much. > > -- > Dean Michael C. Berris > Software Engineer, Friendster, Inc. > [http://cplusplus-soup.blogspot.com/] > [mik...@gm...] > [+63 928 7291459] > [+1 408 4049523] > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > > Cpp-netlib-devel mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel > -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://alexott-ru.blogspot.com/ http://content-filtering.blogspot.com/ http://xtalk.msk.su/~ott/ |
|
From: Dean M. B. <mik...@gm...> - 2007-12-13 13:04:26
|
Hi Alex, On Dec 13, 2007 6:54 PM, Alex Ott <al...@gm...> wrote: > Hello > > Ok, i'll try to write complete suite, and then send it to list. I'm > currently thinking about relations between generic URI's and http > URL's (and other protocols) - for example, setting default ports, etc. > You can go ahead and check the tests into the sandbox or branch from the trunk and work on the URI parser from there. Something like a 'uri-parser' branch which tries to integrate the URI parser into what's already currently in the trunk. When we see that the tests are suitable already, and the implementation bullet-proof, then let's think about merging it into the trunk. :D Or if you're brave and want to take the responsibility of checking it into trunk yourself (the tests and the implementation) then be my guest. :D About the default ports, that may have to be done at the protocol layer. Notice that the request object's constructor can be changed appropriately later. (It's really frustrating that I still currently do not have time to try my hand at implementing the URI parser myself. :( ) -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mik...@gm...] [+63 928 7291459] [+1 408 4049523] |
|
From: Alex O. <al...@gm...> - 2007-12-13 13:15:52
|
Hello On Dec 13, 2007 1:49 PM, Dean Michael Berris <mik...@gm...> wrote: > Hi Alex, > > On Dec 13, 2007 6:54 PM, Alex Ott <al...@gm...> wrote: > > Hello > > > > Ok, i'll try to write complete suite, and then send it to list. I'm > > currently thinking about relations between generic URI's and http > > URL's (and other protocols) - for example, setting default ports, etc. > > > > You can go ahead and check the tests into the sandbox or branch from > the trunk and work on the URI parser from there. Something like a > 'uri-parser' branch which tries to integrate the URI parser into > what's already currently in the trunk. When we see that the tests are > suitable already, and the implementation bullet-proof, then let's > think about merging it into the trunk. :D yes, i know about it, but with it there is one problem with parsing userinfo part - sometimes it not handled properly, and filled with wrong data > Or if you're brave and want to take the responsibility of checking it > into trunk yourself (the tests and the implementation) then be my > guest. :D > > About the default ports, that may have to be done at the protocol > layer. Notice that the request object's constructor can be changed > appropriately later. > > (It's really frustrating that I still currently do not have time to > try my hand at implementing the URI parser myself. :( ) -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://alexott-ru.blogspot.com/ http://content-filtering.blogspot.com/ http://xtalk.msk.su/~ott/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X