]
)
```
where the first parameter is a HTTP method (i.e., `GET`, `POST`, `PUT`, `CREATE` & etc).
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [May 11, 2020, 11:56am UTC](https://discourse.cmake.org/t/extra-http-headers-for-file-upload-download/1152/5 "2020-05-11T11:56:21Z")
@zaufi you’ve been proposing many CMake language features that imply you’re using it as a general-purpose scripting language. Why? It’s meant for configuring project build trees and simple glue scripts. Interacting with REST APIs is well outside that scope. I don’t think we should grow the language that much.
One can use `find_program()/find_package(...)` and `execute_process` do arbitrary things in a true general-purpose language like Python.
---
### Author:  [@zaufi](https://discourse.cmake.org/u/zaufi)
#### Post date: [May 11, 2020, 12:07pm UTC](https://discourse.cmake.org/t/extra-http-headers-for-file-upload-download/1152/6 "2020-05-11T12:07:09Z")
My case:
I’ve added a custom target to build ABI dumps. The result dumps I want to store in JFrog Artifactory at the release build step. The master builds gonna check the ABI changes against the latest release.
Having “external” scripts in Python, means I have to start at lease one repo and full featured Python project which includes: tests, `setup.py`, building package, add CI builds, add a private `pypi` repo and deploy built packages to it, manage to preinstall of this CLI tool into my docker images used to build my projects, use `find_program` in my CMake project, add custom target or output…
All that pain in the ass could be done w/ couple REST API requests to Artifactory… ☹
That is why I strongly believe `http()` command is a better way.
---
### Author:  [@marc.chevrier](https://discourse.cmake.org/u/marc.chevrier)
#### Post date: [May 11, 2020, 12:34pm UTC](https://discourse.cmake.org/t/extra-http-headers-for-file-upload-download/1152/7 "2020-05-11T12:34:23Z")
May be a tool like `curl` will match your needs… with a largely less complex infrastructure than `python`.
---
### Author:  [@erk](https://discourse.cmake.org/u/erk)
#### Post date: [May 11, 2020, 1:04pm UTC](https://discourse.cmake.org/t/extra-http-headers-for-file-upload-download/1152/8 "2020-05-11T13:04:48Z")
> [@zaufi](#):
>
> Having “external” scripts in Python, means I have to start at lease one repo and full featured Python project which includes: tests, `setup.py` , building package, add CI builds, add a private `pypi` repo and deploy built packages to it, manage to preinstall of this CLI tool into my docker images used to build my projects, use `find_program` in my CMake project, add custom target or output…
No sure why you say that.
You can perfectly use a prebuilt python docker image (or any other prebuilt image that contains the tools you need to do REST request) and use it to run a python script which would be stored in your current repo as an helper script just as CMakeLists.txt or other xxx.cmake may be.
I don’t get why you would need a full-blown python module for that?
You may pass anything coming from a CMake build (CI) step as build artifact to the one that needs it.
I don’t know which CI you use but I bet any CI could use various docker images for various step/jobs?
Or may be I missed something in your points?