Save Tgt As.. SM ignores 401, saves auth failed page instead of target - Mozilla

This is a discussion on Save Tgt As.. SM ignores 401, saves auth failed page instead of target - Mozilla ; I've reproduced this in Firefox 2.0.0.6 on win32 and Seamonkey (Iceape) 1.0.8 We have a PDF on an Apache server, in a directory which requires Basic Authentication. We have a link to that PDF in some other, unprotected directory. Right ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Save Tgt As.. SM ignores 401, saves auth failed page instead of target

  1. Save Tgt As.. SM ignores 401, saves auth failed page instead of target

    I've reproduced this in Firefox 2.0.0.6 on win32 and Seamonkey (Iceape) 1.0.8

    We have a PDF on an Apache server, in a directory which requires Basic Authentication.
    We have a link to that PDF in some other, unprotected directory.
    Right click on the link and choose Save Link Target As.

    We *expect* the 401 response from the browser to cause Seamonkey/Firefox to
    dialog, collect the user's credentials (user name and password), and
    retry the access with credentials. If the credentials match, the server
    responds with 200 status and the PDF content. Download Manager shows the
    progress and saves a PDF file.

    But *what happens instead* is Seamonkey doesn't notice the 401 status
    in the response to its initial request with no credentials.
    It collects the HTML "Authorization Failed" message and saves it
    under the PDF's file name. There's no dialog requesting a password.

    Here's a simple test case:
    http://www.greens.org/~cls/mozilla-bug/test.html

    Konqueror, Lynx, and (yecch) MS-IE all do the right thing here.
    Seamonkey and Firefox don't seem to know what 401 means.

    Is this a bug or am I missing something obvious?

    Cameron

  2. Re: Save Tgt As.. SM ignores 401, saves auth failed page insteadof target

    Cameron L. Spitzer wrote:
    > I've reproduced this in Firefox 2.0.0.6 on win32 and Seamonkey (Iceape)
    > 1.0.8
    >
    > We have a PDF on an Apache server, in a directory which requires Basic
    > Authentication.
    > We have a link to that PDF in some other, unprotected directory.
    > Right click on the link and choose Save Link Target As.
    >
    > We *expect* the 401 response from the browser to cause Seamonkey/Firefox to
    > dialog, collect the user's credentials (user name and password), and
    > retry the access with credentials. If the credentials match, the server
    > responds with 200 status and the PDF content. Download Manager shows the
    > progress and saves a PDF file.
    >
    > But *what happens instead* is Seamonkey doesn't notice the 401 status
    > in the response to its initial request with no credentials.
    > It collects the HTML "Authorization Failed" message and saves it
    > under the PDF's file name. There's no dialog requesting a password.
    >
    > Here's a simple test case:
    > http://www.greens.org/~cls/mozilla-bug/test.html
    >
    > Konqueror, Lynx, and (yecch) MS-IE all do the right thing here.
    > Seamonkey and Firefox don't seem to know what 401 means.
    >
    > Is this a bug or am I missing something obvious?
    >
    > Cameron


    Mozilla/5.0 (X11; U; Linux i686; rv:1.9a8pre) Gecko/2007081802
    SeaMonkey/2.0a1pre on Mandriva-2006.1

    First Link:- To see the bug, right-click on THIS LINK and choose Save
    Link Target As.
    result = SeaMonkey checkbox "Authentication-required / Enter username
    and password for "Internal" at http://www.greens.org / User Name: /
    Password: / Use Passwd Mgr to remember passwords / cancel/ OK
    Action = enter secret /secret
    result = 15kB PDF download OK

    Double-check-content, Second-Link:- To get the correct file, go to the
    directory first: HERE and log in
    result = SeaMonkey checkbox "Authentication-required / Enter username
    and password for "Internal" at http://www.greens.org / User Name: /
    Password: / Use Passwd Mgr to remember passwords / cancel/ OK
    Action = enter secret /secret
    result = SeaMonkey plugin Acrobat-reader activates and displays same
    content as viewed in downloaded local 15kB-PDF

    Cameron, this is responding perfectly. Barry.


  3. Re: Save Tgt As.. SM ignores 401, saves auth failed page insteadof target

    Barry_Gilmour wrote:
    > Cameron L. Spitzer wrote:
    >> I've reproduced this in Firefox 2.0.0.6 on win32 and Seamonkey
    >> (Iceape) 1.0.8
    >>
    >> We have a PDF on an Apache server, in a directory which requires Basic
    >> Authentication.
    >> We have a link to that PDF in some other, unprotected directory.
    >> Right click on the link and choose Save Link Target As.
    >>
    >> We *expect* the 401 response from the browser to cause
    >> Seamonkey/Firefox to
    >> dialog, collect the user's credentials (user name and password), and
    >> retry the access with credentials. If the credentials match, the server
    >> responds with 200 status and the PDF content. Download Manager shows the
    >> progress and saves a PDF file.
    >>
    >> But *what happens instead* is Seamonkey doesn't notice the 401 status
    >> in the response to its initial request with no credentials.
    >> It collects the HTML "Authorization Failed" message and saves it
    >> under the PDF's file name. There's no dialog requesting a password.
    >>
    >> Here's a simple test case:
    >> http://www.greens.org/~cls/mozilla-bug/test.html
    >>
    >> Konqueror, Lynx, and (yecch) MS-IE all do the right thing here.
    >> Seamonkey and Firefox don't seem to know what 401 means.
    >>
    >> Is this a bug or am I missing something obvious?
    >>
    >> Cameron

    >
    > Mozilla/5.0 (X11; U; Linux i686; rv:1.9a8pre) Gecko/2007081802
    > SeaMonkey/2.0a1pre on Mandriva-2006.1
    >
    > First Link:- To see the bug, right-click on THIS LINK and choose Save
    > Link Target As.
    > result = SeaMonkey checkbox "Authentication-required / Enter username
    > and password for "Internal" at http://www.greens.org / User Name: /
    > Password: / Use Passwd Mgr to remember passwords / cancel/ OK
    > Action = enter secret /secret
    > result = 15kB PDF download OK
    >
    > Double-check-content, Second-Link:- To get the correct file, go to the
    > directory first: HERE and log in
    > result = SeaMonkey checkbox "Authentication-required / Enter username
    > and password for "Internal" at http://www.greens.org / User Name: /
    > Password: / Use Passwd Mgr to remember passwords / cancel/ OK
    > Action = enter secret /secret
    > result = SeaMonkey plugin Acrobat-reader activates and displays same
    > content as viewed in downloaded local 15kB-PDF
    >
    > Cameron, this is responding perfectly. Barry.
    >

    Its my understanding that when you receive the 401 error it is supposed
    to indicate "File does not exist.

    --
    ------------------------------------------------------------------------
    Phillip M. Jones, CET http://www.vpea.org
    If it's "fixed", don't "break it"! mailtojones@kimbanet.com
    http://www.kimbanet.com/~pjones/default.htm
    Mac G4-500, OSX.3.9 Mac 17" PowerBook G4-1.67 Gb, OSX.4.10
    ------------------------------------------------------------------------

  4. Re: Save Tgt As.. SM ignores 401, saves auth failed page insteadof target

    Phillip M. Jones, C.E.T wrote:
    > Barry_Gilmour wrote:
    >> Cameron L. Spitzer wrote:


    >>>
    >>> We *expect* the 401 response from the browser to cause
    >>> Seamonkey/Firefox to
    >>> dialog, collect the user's credentials (user name and password), and
    >>> retry the access with credentials. If the credentials match, the server
    >>> responds with 200 status and the PDF content. Download Manager shows
    >>> the
    >>> progress and saves a PDF file.


    >>

    > Its my understanding that when you receive the 401 error it is supposed
    > to indicate "File does not exist.


    That's 404.
    401 means try again with a user name and password.
    Both come with an HTML payload. You've seen plenty of 404 pages.

    If you hit a 401 and give a good password, you
    never see the 401 page. if you give a bad password, the server sends
    another 401 and you get another password dialog.
    If you cancel the password dialog, Mozilla tries once more with
    no credentials, and shows you the resulting 401 page this time.


    Cameron


  5. Re: Save Tgt As.. SM ignores 401, saves auth failed page insteadof target

    Barry_Gilmour wrote:
    > Cameron L. Spitzer wrote:
    >> We have a PDF on an Apache server, in a directory which requires Basic
    >> Authentication.


    >> We *expect* the 401 response from the browser to cause
    >> Seamonkey/Firefox to
    >> dialog, collect the user's credentials... and save a PDF file.
    >>
    >> But *what happens instead* is Seamonkey doesn't notice the 401 status
    >> in the response to its initial request with no credentials.
    >> It collects the HTML "Authorization Failed" message and saves it
    >> under the PDF's file name. There's no dialog requesting a password.
    >>
    >> Here's a simple test case:
    >> http://www.greens.org/~cls/mozilla-bug/test.html



    > Mozilla/5.0 (X11; U; Linux i686; rv:1.9a8pre) Gecko/2007081802
    > SeaMonkey/2.0a1pre on Mandriva-2006.1
    >
    > First Link:- To see the bug, right-click on THIS LINK and choose Save
    > Link Target As.
    > result = SeaMonkey checkbox "Authentication-required / Enter username
    > and password for "Internal" at http://www.greens.org / User Name: /
    > Password: / Use Passwd Mgr to remember passwords / cancel/ OK


    That is very odd. I just tried it again, and saved 554 bytes of
    HTML content where the PDF was supposed to go. Never saw any password
    dialog. This is with a new Seamonkey (Well, Iceape) process, that has
    never seen this directory before. And "Firefox" (Iceweasel) does the same.


    > Action = enter secret /secret
    > result = 15kB PDF download OK


    That's expected. When you send credentials, you get the PDF payload.
    You only have to tell Seamonkey your credentials once. It will
    remember them until it exits, even without checking the remember this
    checkbox.
    So if you go to the protected directory and get its automatic index
    first, you'll be prompted for password, and it will work, and then
    when you go for the PDF it will work too. The only failure case
    is going directly for the PDF with a Seamonkey process that has never seen
    this directory before and isn't remembering it from a previous session.


    > Double-check-content, Second-Link:- To get the correct file, go to the
    > directory first: HERE and log in
    > result = SeaMonkey checkbox


    That is weird too, you should not have had to give credentials again
    with the same Seamonkey process. Basic Auth protects directories,
    not individual files. In Apache 2.2 anyway.


    "Authentication-required / Enter username
    > and password for "Internal" at http://www.greens.org / User Name: /
    > Password: / Use Passwd Mgr to remember passwords / cancel/ OK
    > Action = enter secret /secret
    > result = SeaMonkey plugin Acrobat-reader activates and displays same
    > content as viewed in downloaded local 15kB-PDF
    >
    > Cameron, this is responding perfectly. Barry.


    Well I only have hearsay that Firefox-2.0.0.6 on MSWindows-XP
    had the same problem. I don't have a Windows box here to check that with.
    But I do have Ubuntu 7.04 on a test box. Firefox 2.0.0.3, trademark
    and all. Same problem.

    Incidentally, I made the test case on my personal account to reproduce
    a client's problem. He's running Apach2.0 on Mandriva and the
    responses are exactly the same, except his 401 page is fatter than mine.



    Cameron


  6. Re: Save Tgt As.. SM ignores 401, saves auth failed page insteadof target

    Cameron L. Spitzer wrote:
    > Phillip M. Jones, C.E.T wrote:
    >> Its my understanding that when you receive the 401 error it is supposed
    >> to indicate "File does not exist.

    >
    > That's 404.
    > 401 means try again with a user name and password.
    > Both come with an HTML payload. You've seen plenty of 404 pages.
    >
    > If you hit a 401 and give a good password, you
    > never see the 401 page. if you give a bad password, the server sends
    > another 401 and you get another password dialog.
    > If you cancel the password dialog, Mozilla tries once more with
    > no credentials, and shows you the resulting 401 page this time.


    http://en.wikipedia.org/wiki/HTTP_401#4xx_Client_Error

    --
    Please do not email me for help. Reply to the newsgroup
    only. And only click on the Reply button, not the Reply All
    or Reply to Author. Thanks!

    Peter Potamus & His Magic Flying Balloon:
    http://www.toonopedia.com/potamus.htm

  7. Re: Save Tgt As.. SM ignores 401, saves auth failed page insteadof target

    On 08/20/2007 10:30 AM, Peter Potamus the Purple Hippo wrote:
    > Cameron L. Spitzer wrote:
    >> Phillip M. Jones, C.E.T wrote:
    >>> Its my understanding that when you receive the 401 error it is supposed
    >>> to indicate "File does not exist.

    >>
    >> That's 404.
    >> 401 means try again with a user name and password.
    >> Both come with an HTML payload. You've seen plenty of 404 pages.
    >>
    >> If you hit a 401 and give a good password, you
    >> never see the 401 page. if you give a bad password, the server sends
    >> another 401 and you get another password dialog.
    >> If you cancel the password dialog, Mozilla tries once more with
    >> no credentials, and shows you the resulting 401 page this time.

    >
    > http://en.wikipedia.org/wiki/HTTP_401#4xx_Client_Error
    >


    http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html


    10.4.2 401 Unauthorized

    The request requires user authentication. The response MUST include a
    WWW-Authenticate header field (section 14.47) containing a challenge
    applicable to the requested resource. The client MAY repeat the request
    with a suitable Authorization header field (section 14.8). If the
    request already included Authorization credentials, then the 401
    response indicates that authorization has been refused for those
    credentials. If the 401 response contains the same challenge as the
    prior response, and the user agent has already attempted authentication
    at least once, then the user SHOULD be presented the entity that was
    given in the response, since that entity might include relevant
    diagnostic information. HTTP access authentication is explained in "HTTP
    Authentication: Basic and Digest Access Authentication" [43].


    is more authoritative :-)


+ Reply to Thread