Opened 6 years ago

Last modified 6 years ago

#10820 closed bug

W+ can't download file, goes to login.php instead — at Version 5

Reported by: ttcoder Owned by: pulkomandy
Priority: normal Milestone: R1
Component: Applications/WebPositive Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by pulkomandy)

1.3.1 in 47209

Downloads work fine in public sites... But when there is a (cookie based) login wall, file download fails to work in both cases I tested: and (that latter one allows free sign up I think).

For instance say I'm reading my webmail, and one email has an attachement, which I click : instead of getting the file, webpositive instead downloads a login.php file (of MIME type application/xhtml+xml if that matters). It seems the authentication cookie is not propagated in that case. Other use-cases work (e.g. clicking on the "next page" in webmail works, I'm not redirected to the login page).

Change History (5)

comment:1 by beos_zealot, 6 years ago

I have encountered this issue in private torrent tracker sites - instead of "*.torrent" file webpositive downloads "login.php".

comment:2 by ttcoder, 6 years ago

Still there in hrev47259.

#10725 seems to have similar symptoms, maybe this ticket is even a dupe of that one.

in reply to:  2 comment:3 by beos_zealot, 6 years ago

Replying to ttcoder:

Still there in hrev47259.

#10725 seems to have similar symptoms, maybe this ticket is even a dupe of that one.

Tried in two private torrent tracker sites after #10725 fix, but no luck - still downloads "login.php". Tested on Haiku OS x86_64 hrev47380 with HaikuWebKit-1.4.0.

comment:4 by ttcoder, 6 years ago

Still there in hrev47537 / 1.4.0

comment:5 by pulkomandy, 6 years ago

Description: modified (diff)

Ok, I tested this with (the free account lasts 15 days, I hope this will be enough). Here is my interpretation of the problem:

  • We start the request as if we were about to load a new page, but then decide it's going to be a download instead.
  • FrameLoaderClientHaiku::convertMainResourceToDownload is called with the existing request (properly configured with all the needed data)
  • This ultimately calls WebDownloadPrivate constructor with said request as an argument.
  • WebDownloadPrivate creates a new ResourceHandle from that request.

At some point in this, or perhaps a bit later, the cookies for the request get lost. So the "good" initial request ends up not being used (only the headers are parsed), and the request we attempt to use for downloading lacks the cookies, which obviously makes it redirect to the login page.

Note: See TracTickets for help on using tickets.