139554 - HTTP publishing of page with images prompts for username+password even though already supplied in Publish settings.

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[Charles Manske]

1. Start Composer. 
2. Create or open a page with at least one image
3. Use File | Publish as and create or select a site that uses HTTP as the 
publishing url. Be sure the username and password is correct for this site
(in the "Settings" panel).
Be sure "Include images and other files" is checked in the "Publish" panel.
4. Click "Publish". 

Publish Progress dialog will start and the Prompt dialog for username and 
password will be launched. Enter the correct password and publishing will proceed
correctly.
If you repeat all of this (close all mozilla apps first), but don't 
check ""Include images and other files", then you won't get the unecessary 
username and password dialog.
I am not seeing this problem if I publish the same file using FTP.

Comment 1

[Charles Manske]

Attachment: Log of Composer session and publishing a file with 2 images

Comment 2

[Charles Manske]

Attachment: A better log of publishing with images

Comment 3

[Charles Manske]

This problem appeared during the past 3 weeks.

Comment 4

[Darin Fisher]

no chance of fixing this for 1.0

Comment 5

[Darin Fisher]

mass futuring of untargeted bugs

Comment 6

[Samir Gehani]

adt: nsbeta1-

Comment 7

[benc]

uhh. this was reported in 0.9.9...

I've looked at the attached logs, and here is what I can discern:

Send three PUT requests.
When the first request receives a 401...

0[442eb0]: nsHttpChannel::ProcessAuthentication [this=389d228 code=401]
0[442eb0]: challenge=Basic realm="Enterprise Server"
0[442eb0]: nsHttpChannel::GetCredentials [this=389d228 proxyAuth=0
challenges=Basic realm="Enterprise Server"]
0[442eb0]: nsHttpChannel::GetUserPassFromURI [this=389d228]
0[442eb0]: nsHttpChannel::SelectChallenge [this=389d228]
0[442eb0]: nsHttpChannel::GetAuthenticator [this=389d228 scheme=basic]
0[442eb0]: nsHttpAuthCache::GetAuthEntryForDomain [host=blues.mcom.com:80
realm=Enterprise Server]
0[442eb0]: nsHttpBasicAuth::GenerateCredentials [challenge=Basic
realm="Enterprise Server"]
0[442eb0]: nsHttpAuthCache::SetAuthEntry [host=blues.mcom.com:80
realm=Enterprise Server path=/users/cmanske/publish/ metadata=0]
0[442eb0]: Creating nsHttpAuthNode @38a9e58
0[442eb0]: Creating nsHttpAuthCache::nsEntry @38a9f08

re-send first request w/ auth.

process response to second request...

0[442eb0]: nsHttpChannel::ProcessAuthentication [this=38b60f0 code=401]
0[442eb0]: challenge=Basic realm="Enterprise Server"
0[442eb0]: nsHttpChannel::GetCredentials [this=38b60f0 proxyAuth=0
challenges=Basic realm="Enterprise Server"]
0[442eb0]: nsHttpChannel::GetUserPassFromURI [this=38b60f0]
0[442eb0]: nsHttpChannel::SelectChallenge [this=38b60f0]
0[442eb0]: nsHttpChannel::GetAuthenticator [this=38b60f0 scheme=basic]
0[442eb0]: nsHttpAuthCache::GetAuthEntryForDomain [host=blues.mcom.com:80
realm=Enterprise Server]
0[442eb0]: clearing bad credentials from the auth cache
0[442eb0]: nsHttpAuthCache::SetAuthEntry [host=blues.mcom.com:80
realm=Enterprise Server path=(null) metadata=0]
0[442eb0]: Destroying nsHttpAuthCache::nsEntry @38a9f08
0[442eb0]: Destroying nsHttpAuthNode @38a9e58
0[442eb0]: nsHttpChannel::PromptForUserPass [this=38b60f0 realm=Enterprise Server]

So, based on other current, newer bugs, I have a feeling this doesn't happen
anymore, because the complaint is the opposite, once you put something in auth
cache, you can't modify or remove the entry.

Comment 8

[Darin Fisher]

-> default owner