A/R matching against query strings

[Micah Cowan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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.

It seems to me that one usable approach would be to require the ?
query string to be an explicit part of rule, if it's expected to be
matched against query strings. So -A .htm,.gif,*Action=edit* would all
result in matches against the filename portion only, but -A
'\?*Action=edit*' would look for Action=edit within the query-string
portion. (The '\?' is necessary because otherwise '?' is a wildcard
character; [?] would also work.)

The disadvantage of that technique is that it's harder to specify that a
given string should be checked _anywhere_, regardless of whether it
falls in the filename or query-string portion; but I can't think offhand
of any realistic cases where that's actually useful. We could also
supply a --match-queries option to turn on matching of wildcard rules
for anywhere (non-wildcard suffix rules should still match only at the
end of the filename portion).

Another option is to use a separate -A-like option that does what -A
does for filenames, but matches against query strings. I like this idea
somewhat less.

Thoughts?

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
http://micah.cowan.name/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIyrXz7M8hyUobTrERAk+5AJ0ckiE4+bEMEFe9aD8bBNY3HH+IZACdERCs
wab0TyBLCbW/6DYm+8gAExM=
=pwb/
-END PGP SIGNATURE-

Hiding passwords found in redirect URLs

[Micah Cowan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

https://savannah.gnu.org/bugs/index.php?21089

The report originator is copied in the recipients list for this message.

The situation is as follows: the user types wget
http://foo.com/file-i-want;. Wget asks the HTTP server for the
appropriate file, and gets a 302 redirection to the URL
ftp://spag:[EMAIL PROTECTED]. Wget will then issue to the log output, the line:

  Location: ftp://spag:[EMAIL PROTECTED]/mickie/file-you-want

with the password in plain view.

I'm uncertain that this is actually a problem. In this specific case,
it's a publicly-accessible URL redirecting to a password-protected file.
What's to hide, really?

Of course, the case gets more interesting when it's _not_ a
publicly-accessible URL. What about when the password is generated from
one the user supplied? That is, the original request was
http://spag:[EMAIL PROTECTED]/file-i-want, which resulted in a redirect
using the same username/password? Especially if it was an HTTPS request
rather than plain HTTP. A case could be made that it should be hidden in
that case.

On the other hands, in cases like the _original_ example given above,
I'd argue that hiding it could be the wrong thing: the user now has no
idea how to directly access the file, avoiding the redirect the next
time around.

Redirecting to a password-protected file on a different host or using a
different scheme seems broken to me in the first place, and I'm sorta
leaning towards not bothering about it. What are your thoughts, list?

Note: Saint Xavier has already written a fix for this, so it's not
actually a question of whether it's worth the bother, just whether it's
actually desired behavior.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
http://micah.cowan.name/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIytyT7M8hyUobTrERAnC1AJ4pRpWx7z6wRt3Vg4LHyQalEfL3XQCdGTqg
LdK8lQ8tuPTlmCfURcjXPw4=
=ZPrY
-END PGP SIGNATURE-