Compressed App provider could better use the HTTP Protocol

[lucadegasperi]

I've noticed that the Compressed App provider checks what it has to download by only looking at the file extension. In my opinion it should indeed better use the HTTP headers the server sends back and only rely on the file extension as a fallback.
Why this change you would ask?
There are some app providers that do not provide a direct link to the compressed file, they do send a Content-Disposition: attachment; filename="App.zip" indeed.
Also, I think the script should follow HTTP redirects.

While I'm not a ruby developer, I would love someone taking care of this issue.

[wfarr]

You can set a flavor param on the resource to specify whether to treat it as a zipball, tarball, etc.

We'd happily accept PRs to utilize the metadata to do some smarter inferencing or follow redirects.

[bwnoll]

I know this is an old comment, but FWIW, I was able to work around this issue luca pointed out simply by using flavor => 'zip' in the package declaration for a compressed_app package whose source url didn't end in .zip.

[njia]

@bwnoll Any chance you could provide an example ?

[typhonius]

Example for @njia

  package { 'name of package':
    provider => 'compressed_app',
    source   => 'https://www.packagelocation.com/example/no_file_extension',
    flavor   => 'zip',
  }