*add comment on how ambiguous definition of Request_URIs in RFC 2616

is 'solved' by uri-parser

*add comment on record-type server and associated procedures

scheme/lib/url.scm

@@ -7,16 +7,27 @@
 ;;; References:
 ;;; RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1
 ;;; RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax
+;;;
+;;; RFC 2616 adopts definitions of regexps from RFC 2396.
 
+
+;;; RFC 2616 is ambiguous in defining Request_URIS:
+;;;
+;;; section 5.1.2 states:
 ;;; HTTP 1.1 Request-URIS are of the form
 ;;; Request-URI    = "*" | absoluteURI | abs_path | authority
 ;;;
-;;; We implement only the subset
+;;; whilst section 3.2.2 defines the 'http_URL'
-;;; Request-URI    = ( http_URL | abs_path) ["#" fragment]
+;;; http_URL = "http://" host [ ":" port ] [ abs_path [ "?" query ]]
 
+
+;;; Since allowing for general absoluteURIs doesn't make too much sense
+;;; we implement only Request_URIs as follows:
+;;; Request-URI    = ( http_URL | abs_path) ["#" fragment]
+;;;
 ;;; where http_URL is a subset of absoluteURI
 
-;;; and [ "#" fragment ] is allowed even though 
+;;; [ "#" fragment ] is allowed even though 
 ;;; RFC 2616 disallowes the #fragment part 
 ;;; (while RFC 1945 for HTTP/1.0 allowed it).
 ;;; (This is for compatibility with buggy clients).
@@ -165,6 +176,12 @@
 ;;; These are frequently used as the initial prefix of URL's describing
 ;;; Internet resources.
 
+;;Note: the server record-type and its associated procedures are 
+;;a relict of the parsing of general URIs.
+;;Neither HTTP 1.0 nor HTTP 1.1 allow for the 'host'-part (see regexp above) 
+;;of the Request_URI to contain a <user>:<password>@ section
+;;(as long as the ambiguity of the definition of Request_URIs is 'solved' as explained above).
+
 (define-record-type server :server		; Each slot is a decoded string or #f.
   (make-server user password host port)
   server?