One step back on whether to impose stringent control on requested URIs

As agreed upon and encouraged by Andrew, move one step back and not to impose too strict control on requested URI for the time being, until an agreement could be achieved in this respect.

There are pros and cons to invoke xml_is_valid_href() on the requested URI fetched from the FCGI channel, for example:

Pros:
 . History facilities expect to get the name of a device history facility from the requested URI, thus any whitespaces or double slashes will make it failed to do so, thus strict control on the requested URI to have no whitespaces or double slashs are in the benefit of history code
. leading whitespaces will be regarded as a valid href, which is not prohibited but not consistent with the rest of oBIX server implementation
. It's difficult to differentiate among a couple of whitespaces and a tab key

Cons:
 . For the read (GET) requests, more than one slashes in the requested URI are in fact harmless, thanks to the strtok_r() has been able to regard consecutive slashes as one. Therefore permitting only one slash could be an overkill in this respect
. This may upset some applications that don't care that much about the usage of double slashes