If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Still unable to send an attachment to bugzilla

RESOLVED WORKSFORME

Status

()

Core
Networking: HTTP
RESOLVED WORKSFORME
16 years ago
6 years ago

People

(Reporter: Marc Boullet, Unassigned)

Tracking

Trunk
x86
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

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

Comment 1

16 years ago
Created attachment 77632 [details]
Http log: first part (408KB)

Updated

16 years ago
Attachment #77632 - Attachment description: Http log: first part → Http log: first part (408KB)
(Reporter)

Comment 2

16 years ago
Created attachment 77635 [details]
Http log: 2nd part (595KB)

Updated

16 years ago
Attachment #77635 - Attachment description: Http log: 2nd part → Http log: 2nd part (595KB)

Comment 3

16 years ago
-> http
Assignee: new-network-bugs → darin
Component: Networking → Networking: HTTP
QA Contact: benc → tever

Comment 4

16 years ago
marc: can you please re-test with a more recent build?  thx!

Comment 5

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

Comment 6

16 years ago
jkeiser: any chance this might be a problem in form submission land?

Comment 7

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

Comment 8

16 years ago
Created attachment 80219 [details]
Test attachment

Comment 9

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

Comment 11

16 years ago
> ------- Additional Comments From jkeiser@netscape.com  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"

Comment 14

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

Comment 17

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

Comment 18

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

Comment 19

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

Comment 20

15 years ago
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.

Comment 21

11 years ago
-> 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: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.