libcpr / cpr Goto Github PK

This involves enforcing a new directory structure that jekyll is made aware of for holding older .md's that would be used to generate older versions of the documentation.

Official documentation for multi os support is here, and a good reference implementation is the Boost Hana .travis.yml.

A pull request for this would be much appreciated. 🐙

Right now, there's only documentation for how to build the library and tests. This is far from ideal -- the most important piece of information that needs to be put up front is how to integrate this library into an existing or new codebase. Building the library/tests should be in a separate contributors section of the documentation.

Two methods of integration should be detailed:

1. Using git submodules and CMake to build this library as a subproject of a larger application.
2. Using CMake to pull (as in, use find_package) this project into a downstream application if they're in separate project directories. This is an extension of the work done in #28.

Additionally, all of the build options should be enumerated and explained in a separate section.

Some of the callback tests (see #38) are binding objects to a tuple out of bounds using MSVC. Not sure what the fix is, but the callback tests won't compile until this is resolved.

References #26

Most of the constructors in cpr take std::string parameters by const std::string&.

Digest(const std::string& username, const std::string& password);

This is not the most efficient way of dealing with "sink" parameters.
Refer to isocpp/CppCoreGuidelines's parameter passing diagram.

My suggestion is using perfect-forwarding, to always make sure sink std::string members are initialized as efficiently as possible. Example:

#define FWD(...) \
    ::std::forward<decltype(__VA_ARGS__)>(__VA_ARGS__)

template<typename TS0, typename TS1>
Digest(TS0&& username, TS1&& password) :
            Authentication{FWD(username), FWD(password)} {}

Looks like clang-3.6 isn't being found anymore in the dependencies list:

https://travis-ci.org/whoshuu/cpr/jobs/81851148#L129

I tried giving it a go in Visual Studio 2015 Community, and it's mostly OK save for a few fixable issues:

Compilation errors

Linkage errors

Looks like Google Test uses static linkage, while CPR tests use dynamic linkage. There's a CMake variable to make it switch to the CRT DLL, so I'm adding that on Windows to fix this. (IF(WIN32) ... ENDIF())

Write up www.github.io usage and documentation pages to explain how to use all of the current features in 1.0a.

Maybe I'm missing something but I couldn't find a way to do a post request with a custom content-type and raw body which is needed for many REST APIs that expect e.g. JSON in a POST body.

As per RFC 2616, Sec 9.2.

Let's start with just VC 2015 for now.

All of the classes being in the global namespace is probably a no-go for a lot of applications. The right thing to do is to introduce at least one namespace out of respect for those applications.

The most obvious namespace to use is just cpr. If everything is behind that namespace, that should be enough for the most part. Tests can use the normally bad using namespace cpr to avoid onerous changes in that directory.

While looking into exporting test results into XML for actual reporting (more on that later), I saw that tests are passing on my end but marked as failed by CTest.

Looks like this is because the unit tests are destroying some mutex while it's still locked.

9:
9: [----------] 8 tests from CallbackPutTests
9: [ RUN      ] CallbackPutTests.CallbackPutLambdaStatusTest
9: [       OK ] CallbackPutTests.CallbackPutLambdaStatusTest (50 ms)
9: [ RUN      ] CallbackPutTests.CallbackPutLambdaTextTest
9: [       OK ] CallbackPutTests.CallbackPutLambdaTextTest (51 ms)
9: [ RUN      ] CallbackPutTests.CallbackPutLambdaStatusReferenceTest
9: [       OK ] CallbackPutTests.CallbackPutLambdaStatusReferenceTest (51 ms)
9: [ RUN      ] CallbackPutTests.CallbackPutLambdaTextReferenceTest
9: [       OK ] CallbackPutTests.CallbackPutLambdaTextReferenceTest (51 ms)
9: [ RUN      ] CallbackPutTests.CallbackPutFunctionStatusTest
9: [       OK ] CallbackPutTests.CallbackPutFunctionStatusTest (51 ms)
9: [ RUN      ] CallbackPutTests.CallbackPutFunctionTextTest
9: [       OK ] CallbackPutTests.CallbackPutFunctionTextTest (51 ms)
9: [ RUN      ] CallbackPutTests.CallbackPutFunctionStatusReferenceTest
9: [       OK ] CallbackPutTests.CallbackPutFunctionStatusReferenceTest (51 ms)
9: [ RUN      ] CallbackPutTests.CallbackPutFunctionTextReferenceTest
9: [       OK ] CallbackPutTests.CallbackPutFunctionTextReferenceTest (51 ms)
9: [----------] 8 tests from CallbackPutTests (407 ms total)
9:
9: [----------] Global test environment tear-down
9: [==========] 40 tests from 5 test cases ran. (2985 ms total)
9: [  PASSED  ] 40 tests.
9: f:\dd\vctools\crt\crtw32\stdcpp\thr\mutex.c(51): mutex destroyed while busy
9/9 Test #9: cpr_callback_tests ...............***Failed    8.93 sec

0% tests passed, 9 tests failed out of 9

And it looks like this doesn't happen on AppVeyor because this is a debug check, and tests are run in release mode there. They should be switched to debug mode to catch this sort of thing.

I also found the mutex in question in server.cpp:

void runServer(struct mg_server* server) {
    {
        std::lock_guard<std::mutex> server_lock(server_mutex);
        mg_set_option(server, "listening_port", SERVER_PORT);
        server_cv.notify_one();
    }

    do {
        mg_poll_server(server, 1000);
    } while (!shutdown_mutex.try_lock());

    std::lock_guard<std::mutex> server_lock(server_mutex);
    mg_destroy_server(&server);
    server_cv.notify_one();
}

shutdown_mutex is locked in the while condition, but isn't unlocked before exiting the scope. GTest also doesn't notice this as this check is done on-destruction -- and shutdown_mutex is a global object, so this is thrown in the static deinitiailization phase. (:disappointed:)

shutdown_mutex and other assorted utilities should be a class member (and I'm guessing that this wasn't noticed before as this is a test utility class) so any issues would be reported and taken care of at the proper time. (GTest could halt and report a test environment error)

I'm fixing this locally now and pushing in an upcoming PR.

MSVC complains (see #38) that Response has no default constructor when building the tests that use Response inside of a std::future. The fix is probably as simple as adding this:

Response() = default;

to the constructor list.

References #26

This includes the example in the readme documentation.

Faster startup and build times, plus caching dependencies like gcc/curl

I have submitted a PR tu bagder/curl (curl/curl#488) with the same content as the one submitted to your fork, now I'm testing whoshuu/cpr#master with bagder/curl#master and everything seems to work ok (Win7 64bits MSVC2015).

I've just had to choose in CMake between CMAKE_USE_OPENSSL and CMAKE_USE_SCHANNEL because under both macros there is the same definition in curl/lib/urldata.h (line#273 and line#322)

ssl_connect_state connecting_state;

Both seems to be "ON" by default... I don't know what the difference is among all the USE_XXX macros in that file, but I can confirm that last revision works with CPR (I'll try to run all the tests, but my computer crash with them :S)

Update this dependency (after PR merge and tag so install in windows works ok)?

I'm all but a cmake expert but if I interpret this
http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html#creating-packages
link and my cmake output correctly, supplying CPRConfig.cmake
would allow downstream projects to include cpr as a dependency like this:

 set ( CMAKE_PREFIX_PATH ${CMAKE_PREFIX_PATH} vendor/cpr/)
 find_package ( CPR REQUIRED )
 include_directories ( ${CPR_INCLUDE_DIRS} )

and then use ${CPR_LIBRARIES} in target_link_libraries(). Instead of vendoring it could also be installed in the system path getting rid of the first line in the snippet above.

Via http://semver.org/.

As per RFC 5789. Mechanically, the data being sent up should be similar to what's being done for a PUT, even if the semantics are all not the same (PUT's are usually for whole object replacements, PATCH's are usually for partial updates to existing objects).

The curl option to set is this:

curl_easy_setopt(curl_handle, CURLOPT_CUSTOMREQUEST, "PATCH");

The documentation can probably be folded into the header PUT Requests under a more inclusive name. Testing is a bit more involved, but can be done after the main implementation and documentation, which should be easy.

Currently master is a snapshot of the most recent official release, and release/x.x branches are where the most recent development work happens. This isn't ideal because the release branch should be feature stable as bugs are ironed out, and development shouldn't be halted just because a release is taking time to complete.

Hello! I'd like to be able to detect with a finer-grained resolution errors that prevent Curl from performing a request. It seems the right place to start is to change session.cpp:350 to capture the return value from curl_easy_perform(), and then perhaps add some error fields to the cpr::Response that is returned.

I'm happy to open a PR with this feature added if there were interest in it; and if so, I'd like to get your opinion on the right way to structure this feature.