On Sat, Jan 9, 2010 at 15:51, Dean Michael Berris <[email protected]> wrote: > On Sat, Jan 9, 2010 at 10:21 PM, Jeroen Habraken <[email protected]> wrote: >> On Sat, Jan 9, 2010 at 15:01, Dean Michael Berris >> <[email protected]> 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://[usern...@]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 ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
