135399 - Still unable to send an attachment to bugzilla

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect)

Description

[Marc Boullet]

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.

Comment 1

[Marc Boullet]

Attachment: Http log: first part (408KB)

Comment 2

[Marc Boullet]

Attachment: Http log: 2nd part (595KB)

Comment 3

[benc]

-> http

Comment 4

[Darin Fisher]

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

Comment 5

[Christopher Lam]

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

[Darin Fisher]

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

Comment 7

[John Keiser (jkeiser)]

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

[bugs]

Attachment: Test attachment

Comment 9

[bugs]

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.

Comment 10

[John Keiser (jkeiser)]

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

[bugs]

> ------- Additional Comments From [e-mail]  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. :))

Comment 12

[John Keiser (jkeiser)]

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.

Comment 13

[John Keiser (jkeiser)]

Er, instead of "keep the cookie from getting disabled" I meant "keep the cookie
from getting sent"

Comment 14

[bugs]

> 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.

Comment 15

[John Keiser (jkeiser)]

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.

Comment 16

[John Keiser (jkeiser)]

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.

Comment 17

[Marc Boullet]

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

[Darin Fisher]

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

[Darin Fisher]

mass futuring of untargeted bugs

Comment 20

[Miles Bader]

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

[Darin Fisher]

-> default owner

Comment 22

[Matthias Versen [:Matti]]

attaching works without any problems.
Please reopen if this is still an issue.