I was unable to attach an HTTP log to bug #131153 with Mozilla. I had to use IE. This happens to me quite frequently but, since it seems i'm the only one to see that, I didn't file a bug yet. Since I have a HTTP log, I File this bug. Steps: 1. I go to any bug 2. I click on Create a New attachment 3 [details] [diff] [review]. I'm asked for my login password which is automatically filled. I click the login button. 4. I get the attachment page where I enter what I need to enter. 5. I click submit 6. I'm asked, a second time, to enter my login password. This is not always the case, but it seems that the problem always occur when I get this second login form. I click login 7. Then I get the red "You don't specify a file to attach". 8. Back button to the submit form. 9. click submit 10. Alert box: "the document contains no data" though all my previous data are still in the form. I think this is a new behaviour, since before you had the red message again. 11. Took IE to attach my log in 131153 and file this bug 12. I was upset. Back to mozilla. I cleared the cache and set it to "Every time I view the page" (error: I should have made only one change) 12. Next button to the submit form. 13. I noticed that the file name, attachment description were still there, but that additional comments had been cleared. 14. I clicked, without much hope, submit 15. Attachment get submitted. 2001040303 NT4 / squid proxy w/authentication Attaching full log. Do not hesitate to ask, if you need something else.
Attachment #77632 - Attachment description: Http log: first part → Http log: first part (408KB)
Attachment #77635 - Attachment description: Http log: 2nd part → Http log: 2nd part (595KB)
Assignee: new-network-bugs → darin
Component: Networking → Networking: HTTP
QA Contact: benc → tever
marc: can you please re-test with a more recent build? thx!
I'd confirm this. For me this is a *major* hassle, it seriously hampers down my enthusiasm for attaching testcases and patches. I'm using latest nightly 2002041803 on win32.
jkeiser: any chance this might be a problem in form submission land?
From the log, it looks like the login/password we're talking about is proxy login/password. Perhaps it's possible that the format of the message could tell the proxy to force you to log in again, but I am thinking this is more about our proxy support.
I see this with 1.0rc1 on Linux. The message is: Error You did not specify a file to attach. It depends on the second login page, which depends on cookies: If you have the Bugzilla_login cookie set, the second login page doesn't appear, and Bugzilla accepts the attachment. Otherwise Mozilla gets confused, and sends the attachment form data as application/x-www-form-urlencoded, instead of multipart/form-data with the filename (and the file itself). Note: the above is just the work of my fiction, based on some packet analyzing, any resemblance to real code, running or buggy, is purely coincidental. :) I don't even know if a browser would support this double form handling... The proxy doesn't seem to play, unless it is blocking cookies.
How could the Bugzilla_login cookie not get set when you first log in? Bugzilla will not work if the cookie is not set. Bugzilla will also not work if you are not properly logged in (for whatever reason) when you submit the attachment. The login form cannot--*cannot*--send the file attachment through again, even if it wants to. I presume the url-encoded data you saw was when you submitted the login page? The problem here is somewhere before step 6. You should not be asked to log in twice.
> ------- Additional Comments From firstname.lastname@example.org 2002-04-20 17:35 > ------- > How could the Bugzilla_login cookie not get set when you first log in? > Bugzilla will not work if the cookie is not set. There could be any reason, even mozilla offers a lot: see edit->pref->priv&sec->cookies. I think Bugzilla works even with completely disabled cookies. > Bugzilla will also not work if you are not properly logged in (for whatever > reason) when you submit the attachment. The login form > cannot--*cannot*--send the file attachment through again, even if it wants > to. I presume the url-encoded data you saw was when you submitted the login > page? The interesting thing is that this double login works well with the other forms (commenting & changing bugs, voting, etc.), but not with attachment creation. The second-login data captured also contained the fields and their values from the attachment form. (I even tought about a buffer partially overwritten, but I dismissed it because of the lengths.) Please assign somebody with more knowledge about these issues to this bug, I think there is something hidden, worth investigating. This is also something that a good test suite could catch... > The problem here is somewhere before step 6. You should not be asked to log > in twice. I will add this to my "famous last words" collection. :))
FIRST: Again, I need to confirm: was the incorrect "urlencoded" form sent when the login occurred? The reason this works fine with other forms is that they do not send files. Because of the way files are sent, there is just no way to re-send a file the way Bugzilla can re-send other data. SECOND: What cookie prefs do you have enabled? Is there anything you have set that you think *should* keep the cookie from getting disabled? We need this information to make a proper determination of where this bug goes.
Er, instead of "keep the cookie from getting disabled" I meant "keep the cookie from getting sent"
> FIRST: > Again, I need to confirm: was the incorrect "urlencoded" form sent when the > login occurred? Yes, I started capturing at the second login page, it was sent by pressing the login button. Then I got the error message above. > The reason this works fine with other forms is that they do not send files. > Because of the way files are sent, there is just no way to re-send a file the > way Bugzilla can re-send other data. Is it by spec, or by implementation? > SECOND: > What cookie prefs do you have enabled? Is there anything you have set that > you think *should* keep the cookie from getting disabled? I change this all the time (around the strictest settings), and have junkbuster installed, but I have set it up to allow bugzilla cookies. Before that I was getting these error messages too. The test attachment had first failed, then has been created by only changing the cookie settings. The reporter and other people hitting this bug should check and report if they can work around with the same method.
It is Bugzilla's implementation, sort of. There is no way the *browser* can re-send the data but if Bugzilla were to remember the data when it . That is a lot of work, though, and not worth it since Bugzilla says it will not work unless cookies work. If you disabled cookies entirely in IE, this should not work either. If Mozilla is not working when cookies are enabled, that's a different story altogether.
I can reproduce your steps when I have cookies blocked, but *only* when I have cookies blocked. I am betting that is where the problem lies.
My cookie was set to: "enable cookies from the originating web site only". I changed that to: "enable all cookies" according to the previous comments. I tried to attach a file to a bug (136688) and I didn't get any "You don't specify ........" but a lot of "the document contains no data". Finally, after a lot of retries, I succeeded the submit. Note, that even with the new cookie setting, I got the 2nd login. I will post a new HTTP log when I'll have enough time.
marc: interesting... if you are seeing that dialog, it means that you have a sh*tty network connection ;-) see also bug 139164 comment #9. you should not be seeing the dialog... see bug 137965 about fixing cases that erroneously generate it.
mass futuring of untargeted bugs
Target Milestone: --- → Future
I'm using Mozilla 1.1 (from debian unstable), and I _always_ get the redundant `login request' pages, even though I use the default cookie settings (which seems to be `Enable cookies based on privacy settings' / `Medium'. This stops me from submitting attachments... :-( Looking at my stored cookies, I do have various bugzilla cookies in there: `Bugzilla_logincookie', `Bugzilla_login', etc., and the expiration time seems to be verrry far in the future -- at least it looks like it; the date displayed only used a 2-digit year, like `06/30/29 08:56:10', which I guess means 2006. I am behind a firewall (squid I think), though I don't notice any problems with bugzilla other than the annoying redundant logins.
-> default owner
Assignee: darin → nobody
QA Contact: tever → networking.http
Target Milestone: Future → ---
attaching works without any problems. Please reopen if this is still an issue.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.