RFC2616 references RFC2396 as a source of information about URI in the description of a general syntax (Chapter 3.2.1). Then the next chapter (3.2.2) specifies the http URL which /must/ start with the "http:" scheme.
The RFC2396 also don't say noting about a default protocol for such situations. It's a relative URI, so it's responsibility of the application to accept it or not.
In my opinion, a HTTP client should not handle URL not starting with the HTTP scheme altough a browser may do it because a browser support many schemes, and probably default to the http: scheme if none is given (check that with a network sniffer).
An HTTP client is a client for HTTP, so I don't see why can't assume the default protocol as HTTP. But yes, probably better if application set it up with a default protocol. In the other hand, the OverbyteIcsUrl ParseURL procedure already assume HTTP for similar situations, and this may be wrong because it's a generic function, not at application level. Probably better would be to pass the default protocol to use, for when not specified in the URL to be parsed.
By the way, in which real situation are you confronted with URL without scheme ?
This appeared in a relocation of an URL provided by the TwitPic API, so perfectly valid because a relocation can be specified by a relative URL. The HTTPCli was failing to handle such relocation .
Then I thought to extend the handling of such URLs for start URL too, the same way "www.someting.com" or "://www.someting.com" is handled already. This is currently done in the ParseURL, so I added the code there too. But, as I said above, may be wrong for all these situations. Application should pass the default protocol to assume to that ParseURL function. Or the ParseURL should return proto='', and calling code handle it that way. But this will probably brake already existent code.
-- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
