W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 1997

Re: 305/306

From: Ari Luotonen <luotonen@netscape.com>
Date: Tue, 22 Jul 1997 17:29:42 -0700 (PDT)
Message-Id: <199707230029.RAA01243@step.mcom.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3865

> RFC 2068 doesn't contain a regular expression grammar, so of course one
> must be defined before regular expressions can be used in HTTP.  There
> is one in RFC 2168 "Resolution of Uniform Resource Identifiers using the
> Domain Name System", but the authors seem not to like it very much -
> there's a note to the effect that regular expressions are complex and
> error-prone, as well as rarely useful.

While I may agree that regular expressions are more complex than some
other types of wildcard pattern languages, regular expressions in
general are most certainly very useful for some Web applications.  As
an example, Netscape Proxy moved to using regular expressions instead
of shell expressions due to high number of customer requests.  Many
URL patterns simply could not be expressed with shell expressions,
e.g. a pattern that matches URLs without an FQHN.

It may well be that regular expressions are not necessary for the
particular application we're discussing here, but that decision should
be based purely on the application's requirements, not subjective
statements in other RFCs.

The question to pose is, can the 305/306 scope rules be expressed
using the single wildcard '*' as opposed to full regular expressions.
The purist answer is 'no'; you may want to specify a proxy redirection
for non-FQHN URLs.  However, if this seems like an unlikely
application, and a viable trade against simplicity, then yes, maybe
'*' is sufficient.

Ari Luotonen, Mail-Stop MV-061		Opinions my own, not Netscape's.
Netscape Communications Corp.		ari@netscape.com
501 East Middlefield Road		http://home.netscape.com/people/ari/
Mountain View, CA 94043, USA		Netscape Proxy Server Development
Received on Tuesday, 22 July 1997 17:34:04 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:03 UTC