Scott Johnson Reporter
	Description • 22 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130

I have a private intranet page that is protected by basic authentication.  I'm
trying to include images from another server that is protected by basic
authentication.  In my page, I have tags such as <img
src="http://user:passw@other.server/myimage.gif">.  When I load this page into
moz 1.2.1, I am prompted for a login for these images.  IE handles this just
fine.  But I would really love to be able to use this functionality without
having to use IE.

Reproducible: Always

Steps to Reproduce:
1. create a page that contains images with src urls in the form of
http://user:pass@other.server/image.gif
2. load page
Actual Results:  
you will be prompted for a login for the images

Expected Results:  
It should have used the login info from the url to get the images.

	Scott Johnson Reporter
	Comment 1 • 22 years ago

See: ftp://ftp.isi.edu/in-notes/rfc1738.txt (section 3.1)

	Boris Zbarsky [:bzbarsky]
	Comment 2 • 22 years ago

To http networking.

	Ruslan Ismailov
	Comment 3 • 22 years ago

RFC 1728 was updated by FRC 2396

And we could read here:

   The "user:password" form in the previous BNF was changed to a
   "userinfo" token, and the possibility that it might be
   "user:password" made scheme specific. In particular, the use of
   passwords in the clear is not even suggested by the syntax.

Dupe of bug 43889

*** This bug has been marked as a duplicate of 43889 ***

	benc
	Comment 4 • 22 years ago

dupe was incorrect, there is a bug in imagelib about now putting up auth for images.

	Scott Johnson Reporter
	Comment 5 • 22 years ago

I concur that this was an incorrect dupe.  I can type in a url in the fashion
mentioned above just fine in the URL bar, and it works perfectly.  It's only
under the conditions that I specified in this bug report that I've experienced
this behavior.

	Josh Birnbaum
	Comment 6 • 22 years ago

*** Bug 191551 has been marked as a duplicate of this bug. ***

	Darin Fisher
	Comment 7 • 22 years ago

this looks like networking:http to me.  doug: are you working on this?

	benc
	Comment 8 • 22 years ago

maybe this never worked since bug 62108 was implemented? (was imagelib)

I'm still catching up on open bugs, did this EVER work?

	Scott Johnson Reporter
	Comment 9 • 22 years ago

To my knowledge, I was experiencing the side effects of this bug around the same
timeframe of the implementation of bug 62108.  Did I see it before then?  I
don't know.  I'm certain, however, that the bug still exists.

	benc
	Comment 10 • 22 years ago

qa to me. I think this is the same as the other HTTP URL's w/ user:pass bugs.

Scott, do you have a public example of this bug?

	Scott Johnson Reporter
	Comment 11 • 22 years ago

I'll post a public example ASAP.

	Andrew Hagen
	Comment 12 • 21 years ago

*** Bug 184737 has been marked as a duplicate of this bug. ***

	Andrew Hagen
	Comment 13 • 21 years ago

Testcase is from duplicate bug. Confirming on 1.7 beta, Win 98.

	Scott Johnson Reporter
	Comment 14 • 21 years ago

Gosh, almost 11 months have passed since I said I'd get a decent example up
here, but I've finally gotten it ready.  Here it is:

http://insane.com/190854/

When I open this URL in a freshly opened browser, I'm prompted for a login. 
Logins are supplied in the URL for each of the 4 images, so I shouldn't be prompted.

	Scott Johnson Reporter
	Comment 15 • 21 years ago

My example in comment 14 is a bit different than the example in the URL field
above, but they both appear to have the same behavior.

	Scott Johnson Reporter
	Comment 16 • 20 years ago

Is anyone working on this?

	Doug Turner (:dougt)
	Comment 17 • 17 years ago

mass reassigning to nobody.