-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tony Lewis wrote:
> Micah Cowan wrote:
>
>> On expanding current URI acc/rej matches to allow matching against query
>> strings, I've been considering how we might enable/disable this
>> functionality, with an eye toward backwards compatibility.
>
> What about something like --match-type=TYPE (with accepted values of all,
> hash, path, search)?
>
> For the URL http://www.domain.com/path/to/name.html?a=true#content
>
> all would match against the entire string
> hash would match against "content"
> path would match against "path/to/name.html"
> search would match against "a=true"
>
> For backward compatibility the default should be --match-type=path.
>
> I thought about having "host" as an option, but that duplicates another
> option.
As does path (up to the final /).
Would "hash" really be useful, ever? It's never part of the request to
the server, so it's really more "context" to the URL than a real part of
the URL, as far as requests go. Perhaps that sort of thing could best
wait for when we allow custom URL-parsers/filters.
Also, I don't like the name "search" overly much, as that's a very
limited description of the much more general use of query strings.
But differentiating between three or more different match types tilts me
much more strongly toward some sort of shorthand, like the explicit need
for \?; with three types, perhaps we'd just use some special prefix for
patterns to indicate which sort of match we want (":q:" query strings,
":a:" for all, or whatever), to save on prefix each different type of
match with --match-type (or just using "all" for everything).
OTOH, regex support is easy enough to add to Wget, now that we're using
gnulib; we could just leave wildcards the way they are, and introduce
regexes that match everything. Then query strings are '\?.*foo=bar' (or,
for the really pedantic, '\?([^?]*&)?foo=bar(&[^?]*)?$')
That last one, though, highlights how cumbersome it is to do proper
matching against typical HTML form-generated query strings (it's not
really even possible with wildcards). Perhaps a more appropriate
pattern-matcher specifically for query strings would be a good idea.
It's probably enough to do something like --query-='action=Edit', where
there's an implied '\?([^?]*&)?' before, and '(&[^?]*)?$' after.
- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFI/qLZ7M8hyUobTrERAmRdAJsH+9p+mTafoxqeVOstTPKrZP31CACdECCa
vQ1lZnncrdHd8SSbXevK02Y=
=YC2A
-----END PGP SIGNATURE-----
