Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#102 Binary Download

BASE
closed-fixed
Nerveup
Interface (166)
5
2006-02-21
2005-08-29
Christian
No

When i try this all I get is an error msg from IE
telling. "IE was unable to open this Internet Site"

If i try "Save target as" i get the following error msg "The
file could not be written to the cache"

The link looks like this (IP removed)
https://xxx.xxx.x.xxx/base-php4/base_payload.php?
submit=%230-%284-1320
12%29&download=1&cid=132012&sid=4&asciiclean=0

/Christian

Discussion

  • Logged In: NO

    Hello, I tested that patch I wrote
    with an old internet explorer 4 under windows 98 successfully. So I wonder what kind of "cache" are you talking about.

    Clicking at that link
    should have automatically launched the usual dialog about what to do with the file...

    Maybe you should give
    some information about the web server,
    the php version in question, the ie
    version.

    And the URL is not that important. Much more important are the http headers sent by the web server. In the past there were some problems with generating the http headers with php. It
    is almost an faq.

    Juergen Leising

     
  • Logged In: NO

    ahhh, I forgot -

    do you have the same problems with any other browser, too?

    Juergen

     
  • Christian
    Christian
    2005-09-07

    Logged In: YES
    user_id=1155549

    Looks like someone has done some code changes because
    now it opens the url.

    From apache log
    "GET /base-php4/base_payload.php?submit=%231-%283-
    428886%29&download=1&cid=428886&sid=3&asciiclean=1
    HTTP/1.1" 200 1380 "https://xxx.xxx.x.xxx/base-
    php4/base_qry_alert.php?submit=%231-%283-428886%
    29&asciiclean=1" "Mozilla/4.0 (compatible; MSIE 6.0;
    Windows NT 5.1; .NET CLR 1.1.4322)" "-"

    It displays something

    HTTP/1.1 200 OK
    Content-Length: 8563
    Content-Type: image/jpeg
    Last-Modified: Thu, 28 Jul 2005 09:06:55 GMT
    Accept-Ranges: bytes
    ETag: "b8a1c6b35393c51:8a5"
    Server: Microsoft-IIS/6.0
    X-Powered-By: ASP.NET
    Date: Wed, 07 Sep 2005 11:23:07 GMT

    JFIF``C
    

    But that does not look correct (odd chars).

    If i try save target as i get the same error as before.

    I dont have any other browsers to test with.

    /Christian

     
  • Logged In: YES
    user_id=1341286

    Ok,

    with those headers it is actually no wonder that your
    download fails.
    The question is: where do they come from?

    1. This is strange:

    > Content-Type: image/jpeg

    If this is really sent to your browser, then, of course, the
    browser
    wants to display an image... Then it's not the browser's
    fault. But
    in any case: image/jpeg HAS TO go away.

    (a different question is, whether internet explorer is
    allowed to
    display data claimed to be a jpeg, but that turns out not to
    be a jpeg:
    broken image would have been correct)

    2.

    > Server: Microsoft-IIS/6.0

    hmmm, this is not apache, is it. Is this an
    intentionally faked name or is this web server (or
    any other web|cache|proxy server) server between apache
    and your browser? Such a go-between could
    be the reason for those strange headers. Basically the headers
    generated by base_payload.php should find their way to your
    browser... and not any other phantasy like headers.

    Can you circumvent IIS, i. e., can you enforce that your browser
    sees apache output?

    3. Anyway, please have a look at the file
    "base.php4/base_payload.php".
    There should be code like

    /****** database contains hexadecimal *******************/
    if ( $myrow2[0] ){
    if ($myrow3[0] == 0){
    header ("Content-type:
    application/octet-stream");
    header ("Content-Disposition:
    filename=payload.bin");
    header ("Content-Transfer-Encoding:
    binary");
    header ("Pragma: no-cache");

    and some lines later

    /********database contains base64 *******************/
    } elseif ($myrow3[0] == 1){
    header ("Content-type:
    application/octet-stream");
    header ("Content-Disposition:
    filename=payload.bin");
    header ("Content-Transfer-Encoding:
    binary");
    header ("Pragma: no-cache");

    a) Those header commands are the crucial ones. There MUST
    NOT be output anything
    before those headers get sent. This means, that there MUST
    NOT even be a space or
    carriage return be output, and that base_payload.php really
    has to start
    with "<?php" and not with any html before, be it a space or
    a tab or a return
    or anything else.

    b) The "Content-type" lines really have to contain
    "application/octet-stream".
    jpeg is wrong. Images get downloaded immediately ("inline"),
    but we want
    a proper dialogue about what to do with the file: "save as",
    or "open
    with" an editor or debugger or whatever.

    c) The "Content-Disposition-Lines" are adjusted to the needs
    of the
    internet explorer. RFC 2616 (19.5.1) and RFC 1806 (page 2)
    would require

    Content-Disposition: attachment; filename="payload.bin"

    but internet explorer 5.5 is known to ignore a line like
    this one.
    Version 5.5 seems to understand only the short form I used
    above.
    Additionally there are the quotes: some browsers interpret them
    as part of the filename.

    So I prefer to leave it as it is, as most other browsers seem to
    eat the short form in any case, although it's a violation of
    standards.

    d) If anything between apache and your browser simply
    deletes the
    Content-Disposition line, the download should work
    nevertheless, although
    with some limitations:

    For example, if I have my internet explorer 4 go via squid,
    and that squid is configured to filter the
    Content-Disposition line,
    the download is much slower, the filetype does not get
    detected properly
    and the filename is anything but the configured one.

    But in case of emergency: the "Content-Disposition" line is not
    essential; the "Content-Type" line, however, IS VITAL: We
    can not
    do without application/octet-stream.

    e) The transfer encoding header is not important.
    It is said to make things more stable, well... In your
    case it does not get through, either.

    f) Maybe you should add after each Pragma lines:

    header ("Cache-Control: no-cache, public,
    must-revalidate");

    But this clearly does not solve the problem where the reported
    headers come from.

    Bye, bye

    Juergen

     
  • Christian
    Christian
    2005-09-09

    Logged In: YES
    user_id=1155549

    This is really anoying, but on the "good" side i tested with
    Firefox and in there it works as it should.

    1. When I in IE try to d/l a payload that is pure text it will
    open that in a new window (right click same issue as before)
    When its not pure text IE gets confused what to do, that is
    prolly why I get that strange Content-Type.

    2. The server is apache and nothing else i have no thing
    between me and the server so thats just a bad respond.

    From what i can tell this is isolated to IE it would be great if
    someone with an "old" version of IE could test and see if it
    has the same issue.

    Im Using 6.0.2800.1106.xpsp2.050301-1526 with all the latest
    patches.

    /Christian

     
  • Nerveup
    Nerveup
    2006-02-20

    Logged In: YES
    user_id=1429350

    Yeah. I can reproduce this too.
    As nobody said: "Internet Explorer does not eat
    "Pragma:no-cache" under SSL."

    What if we remove pragma:no-cache and add sig and cid to
    filename?

     
  • Nerveup
    Nerveup
    2006-02-20

    • assigned_to: secureideas --> nerveup
    • status: open --> open-accepted
     
  • Nerveup
    Nerveup
    2006-02-21

    • status: open-accepted --> closed-fixed