> -----Original Message-----
> From: Yutaka Sato [mailto:email@example.com]
> Sent: Tuesday, September 07, 1999 5:53 PM
> To: firstname.lastname@example.org
> Cc: david@ohiolink..
> Subject: Re: [DeleGate-En] username and password in url
> On 09/07/99(21:58) you "David Barber" <email@example.com> wrote
> in <_A576@delegate-en.ML_>
> |I wonder if anyone can help me figure out how to mount and/or
> filter a site
> |that I am having problems with. When first contacted, the site
> returns a
> |Location redirect. The url given is in a form like
> |http://username:password@server../login . If I just use
> delegate as a
> |proxy, the remote browser responds to the url properly and at the
> |appropriate time it uses the username and password to do a
> |basic-authentication with the remote server.
> I'm curious where and who does this translation, from "username:password"
> in request URL to the one in Authorization header of request message
> to server.
Apparently although the use of a username:password combination is only
permitted in the RFC for FTP urls, browsers will automatically use the
username and password in a basic authentication header to get that URL. I
have tried this with IE and Netscape. I think it is poor site design to
utilize this capability which by my way of thinking amounts to a bug in the
> |However, when I mount
> |www.server.com as /server the browser does not respond
> appropriately to the
> |remote server and the user is shown a prompt with a username
> and password.
> |I am at a loss as to how to where the problem is and how to filter the
> |responses or the requests to enable my users to remotely access
> this site.
> I suppose that the problem is caused because DeleGate does not insert
> "username:password@" into URL in Location header in response message
> to client.
> But I suppose this problem should occur regardless of usage of MOUNT...
I finally figured out what was going on with my filters and the site and
have made it work. The remote site was sending out different content for
different browser types. When I tried contacting the site via telnet to its
Port 80 and telling it that the User-agent was Mozilla/4.0, I found that
what was happening was the browser received a BASE HREF element in the
document header. This was of the form, username:password@server..,
and then there was a frameset in the body of the document that gave a
relative URL to the content of the frame. The net result of this situation
was that Delegate did not recognize the BASE HREF URL
username:password@server.. as a www.server.com url it should rewrite
to /server and Delegate did rewrite the relative url to /server with a
prefix giving the name and port of my server. Consequently, the remote
browser did not receive the proper URL for that frame.
The solution was to write a filter that looked for the BASE HREF header
element and extracted the username and password. It also rewrote the BASE
HREF to point to username:password@mymountedserver../server. With the
extracted username and password, it then also changed the frameset url from
Now it seems to be working fine. Thinking about this in retrospect, I do
not think I would recommend any changes to Delegate to handle this
situation. It seems like such a weird site design that I do not think it
reasonable to think you should spend any time on handling it.
> |If you have any ideas or suggestions, please let me know. Even
> if you do
> |not know what the solution is, it might help if you can tell me
> how to write
> |a filter that logs the complete communication between the client and the
> |server using ftocl and fromsv. If I can do this, it might shed
> some light
> |on what the browser or server are sending and when.
> On Unix, you can use "tee" command which simply writes out the content
> of communication it relaying to an arbitrary file.
> DeleGate has a built-in filter "-tee" which acts like "tee" command, but
> with some original options including "-n" (with line number), "-h"
> (header only). Without given file name, "-tee" writes out to standard
> output, thus for example, the following will dump what is sent to server
> and client onto your terminal:
> % delegated -v FTOSV="-tee-n" FTOCL="-tee-n-h" ...
Thanks for the info on the TEE command it should help in debugging what
happens with other sites.
> Yutaka Sato <firstname.lastname@example.org> http://www.etl.go.jp/~ysato/ @ @
> Computer Science Division, Electrotechnical Laboratory ( - )
> 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan _< >_