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. 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? >> >> 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 ------------------------------------------------------------------------------ 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
