cli icon indicating copy to clipboard operation
cli copied to clipboard

Exit status "4" when using download with continue and file is already present

Open mike-pt opened this issue 5 years ago • 13 comments

% sudo http --debug --check-status --follow -bdco file.tar.bz2 URL.file.tar.bz2
HTTPie 1.0.3
Requests 2.22.0
Pygments 2.4.1
Python 3.6.9 (default, Dec 24 2019, 01:17:36) 
[GCC 4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)]
/usr/local/bin/python3.6
FreeBSD 12.1-RELEASE-p1


    "colors": 8,
    "config": {
        "__meta__": {
            "about": "HTTPie configuration file",
            "help": "https://httpie.org/doc#config",
            "httpie": "1.0.3"
        },
        "default_options": "[]"
    },
    "config_dir": "/root/.httpie",
    "is_windows": false,
    "stderr": "<_io.TextIOWrapper name='<stderr>' mode='w' encoding='US-ASCII'>",
    "stderr_isatty": true,
    "stdin": "<_io.TextIOWrapper name='<stdin>' mode='r' encoding='US-ASCII'>",
    "stdin_encoding": "US-ASCII",
    "stdin_isatty": true,
    "stdout": "<_io.TextIOWrapper name='<stdout>' mode='w' encoding='US-ASCII'>",
    "stdout_encoding": "US-ASCII",
    "stdout_isatty": true
}>

    "allow_redirects": true,
    "auth": "None",
    "cert": "None",
    "data": {},
    "files": {},
    "headers": {
        "Accept-Encoding": "identity",
        "Range": "bytes=142370763-",
        "User-Agent": "HTTPie/1.0.3"
    },
    "method": "get",
    "params": {},
    "proxies": {},
    "stream": true,
    "timeout": 30,
    "url": "https://URL/file.tar.bz2",
    "verify": true
})
% echo $?
4

This makes it a hard to test for 40x http errors. Is this by design or a bug?

mike-pt avatar Jan 22 '20 16:01 mike-pt

FWIW this is my way of handling it for now, but it seems wrong to show "4" in such cases.

http --follow -bdco "$file" $download_url 
  exit_code=$?
  if [ "$exit_code" != "0" ]; then
    if [ "$exit_code" == "4" ] && [ -f "$file" ]; then
      echo -e "We already have this file on disk, moving on...\n\n"
    else
      echo -e "Something failed attempting to download package!\nURL: $download_url\n Exit Code: $exit_code\n"
      exit 1
    fi
  fi

mike-pt avatar Jan 22 '20 16:01 mike-pt

Can you include the entire output of the first example?

jkbrzt avatar Jan 23 '20 14:01 jkbrzt

that's the entire output when the file already exists actually

mike-pt avatar Jan 23 '20 21:01 mike-pt

or do you mean with headers too?

mike-pt avatar Jan 23 '20 21:01 mike-pt

Just copy the entire output.

jkbrzt avatar Jan 24 '20 11:01 jkbrzt

In that case that is it, I just replaced the real url for privacy reasons, all else is there.

In other words, there is no output to stdout when the file already exists!

mike-pt avatar Jan 24 '20 17:01 mike-pt

I don’t need the exact url. But without the compete output (headers, progress, etc.) I can’t help.

jkbrzt avatar Jan 25 '20 08:01 jkbrzt

But how can I provide any output when none exists!? Or are ou saying it should!? What happens your side when you try to do the same? I mean download a url with -co when the file was already downloaded... do you see output!? I see nothing (no progress even) and the exit code is 4.

I can get the headers if I send -hfor sure, (that's what I was asking above, and it seems to be the culprit actually:

(EDITED: my fat finger typed enter too fast)

HTTP/1.1 416 Requested Range Not Satisfiable
Age: 102
CF-Cache-Status: HIT
CF-RAY: 55b3de858b8ada76-LIS
Cache-Control: public, max-age=259200
Connection: keep-alive
Content-Disposition: attachment; filename="file.tar.bz2"; filename*=UTF-8''file.tar.bz2
Content-Range: bytes */142462219
Content-Type: text/html
Date: Sun, 26 Jan 2020 16:30:03 GMT
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Expires: Wed, 29 Jan 2020 16:30:03 GMT
Server: cloudflare
Set-Cookie: __cfduid=d3093fe2d895aa6d99e2ca6ead65a6a811580056203; expires=Tue, 25-Feb-20 16:30:03 GMT; path=/; domain=.example.org; HttpOnly; SameSite=Lax
Transfer-Encoding: chunked
Vary: Accept-Encoding

So its because of HTTP/1.1 416 Requested Range Not Satisfiable I assume?

What I don't understand now is why, but that might not be httpie issue anyway but the server?

mike-pt avatar Jan 26 '20 16:01 mike-pt

Just an update on this I later found the file is also always created (0 byte) if the requests fails!

I.e even on 404 the request would fail but we create a 0 byte file! I noticed cause to work around the 416 I was using test -f in the shell script and it was passing; just curios if that is the intended behavior? (fine by me I'll just change the test to -s but just wanted to be sure that's intended)

mike-pt avatar Feb 17 '20 23:02 mike-pt

@mike-pt could you please provide a minimal test case, and describe what the expected & the actual behavior is? We’re having troubles reproducing it. Thanks!

jkbrzt avatar Jun 18 '20 13:06 jkbrzt

Hum its been some time, the original issue was a odd one, I try to repo again but about that last comment:

miguelc@r2d2:~ % http -h -dco /tmp/file.txt https://domain.com/file.FAKE
HTTP/1.1 404 Not Found
Age: 107
CF-Cache-Status: HIT
CF-RAY: 5a55d0485f78067e-LHR
Cache-Control: public, max-age=259200
Connection: keep-alive
Content-Type: application/json;charset=ISO-8859-1
Date: Thu, 18 Jun 2020 14:48:51 GMT
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Expires: Sun, 21 Jun 2020 14:48:51 GMT
Server: cloudflare
Set-Cookie: __cfduid=df76b0fc75da7cf72600cf683995c29b81592491731; expires=Sat, 18-Jul-20 14:48:51 GMT; path=/; domain=.plex.tv; HttpOnly; SameSite=Lax
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Artifactory-Id: abc0aca8c8fcf70f:-1015742d:1726eb5d906:-8000
X-Artifactory-Node-Id: artifactory00
cf-request-id: 03698081360000067ee61d0200000001

% file /tmp/file.txt
/tmp/file.txt: empty
% ls -l /tmp/file.txt
-rw-r--r--  1 miguelc  wheel  0 Jun 18 15:48 /tmp/file.txt

note that I do not pass -b here, if I did I would actually get this was the output:

{
  "errors" : [ {
    "status" : 404,
    "message" : "File not found."
  } ]
}

Not sure if that is the intend behavior of if we should end up with no file there, I assume we are creating the file first and then writing the contents to it, or because we could somehow get actually 0 content (download gets canceled at start, unlikely but not impossible); In any case my question there was really if that's the expected case or not.


About the original issue I later posted that this happens cause I get a 416 if the file is already on disk with the full content-length (https://github.com/jakubroztocil/httpie/issues/842#issuecomment-578518068) the content-range is */totalsize and so I get a 416.

If so, httpie simple returns a single digit exit code ofc, and so a 416 is still a 4, I was just not noticing the 416 at that at the time.

In other words that is not a bug.

mike-pt avatar Jun 18 '20 15:06 mike-pt

I think I've missed that it was intentionally a 404 response. So the actual issue here is that us creating an empty file when the server responds something other than 200, right?

isidentical avatar Dec 28 '21 12:12 isidentical

I see this discussion concluded with an empty file from a 404 response, but I have exactly the problem described in the title, with no 404 errors involved. This is also related to the same problem in curl: https://github.com/curl/curl/issues/10521

I tried running https -dco foo.bin ***redacted_url*** X-JFrog-Art-Api:@jfrog-api-key to download a build artifact from an artifactory server, hoping that repeated script runs would not download the large file multiple times.

The server replies with

HTTP/1.1 416 Requested Range Not Satisfiable
Connection: keep-alive
Content-Length: 0
Content-Range: bytes */977880575
Date: Wed, 09 Aug 2023 09:57:07 GMT
Server: nginx/1.18.0 (Ubuntu)
X-Artifactory-Id: ***redacted***
X-Artifactory-Node-Id: ***redacted***
X-Jfrog-Version: Artifactory/7.55.13 75513900

letting httpie exit with code 4.

The corresponding request was

Accept: */*
Accept-Encoding: identity
Connection: keep-alive
Host: artifactory.redacted.lan
Range: bytes=977880575-
User-Agent: HTTPie/3.2.1
X-JFrog-Art-Api: ***redacted***

hmeine avatar Aug 09 '23 10:08 hmeine