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

RESOLVED WONTFIX

Status

()

Core
Networking
--
major
RESOLVED WONTFIX
16 years ago
2 years ago

People

(Reporter: Charles Manske, Unassigned)

Tracking

({regression})

Trunk
All
Windows 2000
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: publish)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Created attachment 80637 [details]
Log of Composer session and publishing a file with 2 images
(Reporter)

Updated

16 years ago
Keywords: nsbeta1
Whiteboard: publish
Target Milestone: --- → mozilla1.0
(Reporter)

Comment 2

16 years ago
Created attachment 80638 [details] [diff] [review]
A better log of publishing with images
(Reporter)

Updated

16 years ago
Attachment #80637 - Attachment is obsolete: true
(Reporter)

Comment 3

16 years ago
This problem appeared during the past 3 weeks.
Keywords: regression

Comment 4

16 years ago
no chance of fixing this for 1.0
Target Milestone: mozilla1.0 → mozilla1.0.1

Updated

16 years ago
Target Milestone: mozilla1.0.1 → ---

Comment 5

16 years ago
mass futuring of untargeted bugs
Target Milestone: --- → Future

Comment 6

15 years ago
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

Comment 7

15 years ago
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.
QA Contact: tever → cpetersen0953

Comment 8

12 years ago
-> default owner
Assignee: darin → nobody
Component: Networking: HTTP → Networking
QA Contact: chrispetersen → networking
Target Milestone: Future → ---
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.