New Post: NuGet package for Visual Studio 2015 not works

October 8, 2015, 1:02 pm

≫ Next: Edited Issue: Jenkins GatedCheckin: setup prebuild merge [202]

≪ Previous: New Post: NuGet package for Visual Studio 2015 not works

$

0

0

hey atono

We will be fixing this issue in our next release, 2.7.0. The tentative timeline for the release is end of next week (8/16).

Thanks
Kavya

---

Edited Issue: Jenkins GatedCheckin: setup prebuild merge [202]

October 8, 2015, 2:09 pm

≫ Next: Commented Unassigned: Uri encoding API doesn't appear to encode query values correctly [417]

≪ Previous: New Post: NuGet package for Visual Studio 2015 not works

$

0

0

We have setup Gated commit using Jenkins.
Developers must push their changes to the staging branch. The GatedCheckin project will perform validation and push the changes to origin/development.

However, If your feature branch is not up-to-date with the origin/development, the push from Jenkins after gated commit validation will fail (with the below error:
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again. See the..)
We will run into this if someone tries to submit changes when a gatedcheckin build is currently running.

Jenkins has a "pre-build merge" option which might solve this issue for us. However I am running into some issues setting this up:
Checking out the repo on the slave machines is failing:
Building remotely on casa_gated (wingated) in workspace <http://casa_linux/job/GatedCheckin/label=wingated/ws/>
> C:\Program Files (x86)\Git\bin\git.exe rev-parse --is-inside-work-tree Fetching changes from the remote Git repository > C:\Program Files (x86)\Git\bin\git.exe config remote.origin.url https://git01.codeplex.com/casablanca
Fetching upstream changes from https://git01.codeplex.com/casablanca
> C:\Program Files (x86)\Git\bin\git.exe --version > C:\Program Files (x86)\Git\bin\git.exe fetch --tags --progress https://git01.codeplex.com/casablanca +refs/heads/*:refs/remotes/origin/*
Checking out Revision a8dc7afdb609d572c5d7cfa8864295310c9e9e2a () > C:\Program Files (x86)\Git\bin\git.exe config core.sparsecheckout > C:\Program Files (x86)\Git\bin\git.exe checkout -f a8dc7afdb609d572c5d7cfa8864295310c9e9e2a
FATAL: Could not checkout null with start point a8dc7afdb609d572c5d7cfa8864295310c9e9e2a
hudson.plugins.git.GitException: Could not checkout null with start point a8dc7afdb609d572c5d7cfa8864295310c9e9e2a
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$8.execute(CliGitAPIImpl.java:1497)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:328)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at hudson.remoting.Engine$1$1.run(Engine.java:63)
at java.lang.Thread.run(Unknown Source) Caused by: hudson.plugins.git.GitException: Command "C:\Program Files (x86)\Git\bin\git.exe checkout -f a8dc7afdb609d572c5d7cfa8864295310c9e9e2a" returned status code 128:
stdout:
stderr: fatal: reference is not a tree: a8dc7afdb609d572c5d7cfa8864295310c9e9e2a

Commented Unassigned: Uri encoding API doesn't appear to encode query values correctly [417]

October 8, 2015, 2:43 pm

≫ Next: Edited Unassigned: Uri encoding API doesn't appear to encode query values correctly [417]

≪ Previous: Edited Issue: Jenkins GatedCheckin: setup prebuild merge [202]

$

0

0

The uri_builder class has set_query and append_query methods that take a string, and a flag to indicate whether encoding is required. The documentation states that the query separator (ampersand) character is taken care of, so we don't need to worry about it.

Problem is, I have a query key/value pair where the key is "realm" and the value is "R&D". I need the encoding API to recognise this, and create the query string of "realm=R%26D", however it encodes it as "realm=R&D".
Comments: hey gigaplex, uri_builder has an append_query overload that takes 3 arguments: name, value and third parameter to specify whether to apply URI encoding. This overload can be used in your case, to selectively encode the query string value before passing it to append_query. This is the option you want: ``` const std::wstring realmvalue(L"R&D"); uri_builder builder1(L"/testquery"); builder1.append_query(L"realm", uri::encode_data_string(realmvalue), false); wprintf(L"URI:%s\n", builder1.to_string().c_str()); // Output: URI:/testquery?realm=R%26D ``` I am going to resolve the issue. Thanks Kavya.

Edited Unassigned: Uri encoding API doesn't appear to encode query values correctly [417]

October 8, 2015, 2:43 pm

≫ Next: New Post: Incorrect POST format

≪ Previous: Commented Unassigned: Uri encoding API doesn't appear to encode query values correctly [417]

$

0

0

The uri_builder class has set_query and append_query methods that take a string, and a flag to indicate whether encoding is required. The documentation states that the query separator (ampersand) character is taken care of, so we don't need to worry about it.

Problem is, I have a query key/value pair where the key is "realm" and the value is "R&D". I need the encoding API to recognise this, and create the query string of "realm=R%26D", however it encodes it as "realm=R&D".

New Post: Incorrect POST format

October 8, 2015, 9:30 pm

≫ Next: New Post: NuGet package for Visual Studio 2015 not works

≪ Previous: Edited Unassigned: Uri encoding API doesn't appear to encode query values correctly [417]

$

0

0

I'm trying to create a post to a server to send an SMS message and what comes out of CPPREST is not correctly formatted. The code below makes the request to my company's Web server, which has no idea what do do with it, but allows me to capture the request in WireShark.

#include <cpprest/http_client.h>

int wmain(int argc, wchar_t *argv[])
{
    using namespace ::std;
    using namespace ::web::http;
    using ::web::http::client::http_client;

    uri_builder base_uri(U("http://edulinksys.com"));
    base_uri.set_user_info(U("username:password"));

    http_client client(base_uri.to_uri());

    uri_builder request_uri(U("/sms"));
    request_uri.append_query(U("destinationAddress"), "2125551212")
        .append_query(U("sourceAddress"), U("2125551213"))
        .append_query(U("message"), U("test message"));

    http_request request(methods::POST);
    auto &headers = request.headers();
    headers.add(header_names::content_type, U("application/x-www-form-urlencoded"));
    headers.add(header_names::accept, U("application/json"));
    request.set_request_uri(request_uri.to_uri());

    client.request(request).then(
    [](http_response response)
    {
        wcout << response.to_string();
    }).wait();

    return 0;
}

The request looks like this on the wire:

POST /sms?destinationAddress=2125551212&sourceAddress=2125551213&message=test%20message HTTP/1.1
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Accept: application/json
User-Agent: cpprestsdk/2.6.0
Content-Length: 0
Host: edulinksys.com

My admittedly less than expert level of understanding tells me that this is not the correct format. The first line should be approximately "POST /sms HTTP/1.1" and the query string should be in the body, under the "Host:..." line.

I have tried numerous ways to put the request together with uri_builders, http_clients and http_requests; all produce the same results. Who's wrong, me or CPPREST?

-evan

New Post: NuGet package for Visual Studio 2015 not works

October 8, 2015, 10:10 pm

≫ Next: New Post: http listener not listening on "invalid" uri's

≪ Previous: New Post: Incorrect POST format

$

0

0

That is great news! It will resolve the open issue: https://casablanca.codeplex.com/workitem/400

New Post: http listener not listening on "invalid" uri's

October 8, 2015, 11:19 pm

≫ Next: New Post: NuGet package for Visual Studio 2015 not works

≪ Previous: New Post: NuGet package for Visual Studio 2015 not works

$

0

0

Hey Guys,

I'm using the listener on localhost and nearly everything works smoothly, but during testing I now ran into a problem. Whenever I'm trying to access the listener through in invalid uri scheme, the listener isn't notified about my request and therefore nothing happens.

In particular I'm trying to request the uri

http://localhost:7070/endpoint?id=[test]

unencoded and nothing happens! No response, no exception, nothing! Encoded as

http://localhost:7070/endpoint?id=%5Btest%5D

the request is noticed and correctly responded to.

Is this behaviour expected? If so, how is it possible to implement any service-sided feedback for requests on invalid uri's or is any client always responsible for ensuring the uri being valid?

Thanks in advance,
Frederic

New Post: NuGet package for Visual Studio 2015 not works

October 9, 2015, 12:36 am

≫ Next: Edited Issue: Android with VS 2015 RTM - default Clang version is no longer 3.4 NuGet packages end up turned off [400]

≪ Previous: New Post: http listener not listening on "invalid" uri's

$

0

0

Great!

Rino

---

Edited Issue: Android with VS 2015 RTM - default Clang version is no longer 3.4 NuGet packages end up turned off [400]

October 9, 2015, 10:03 am

≫ Next: New Post: Incorrect POST format

≪ Previous: New Post: NuGet package for Visual Studio 2015 not works

$

0

0

Reported from the following discussion:

https://casablanca.codeplex.com/discussions/641769

Basically the problem is the Android NuGet packages only will add the files if the Clang version is 3.4. The default Clang version changed in RTM.

New Post: Incorrect POST format

October 9, 2015, 10:41 am

≫ Next: New Post: Incorrect POST format

≪ Previous: Edited Issue: Android with VS 2015 RTM - default Clang version is no longer 3.4 NuGet packages end up turned off [400]

$

0

0

Surprise, surprise, it's me that's wrong. Apparently, if you want some text in the body of an HTTP request you need to actually put it there. And if you don't want some text in the URI you shouldn't pass it to http_request::set_request_uri().

So far, changing the line "request.set_request_uri..." to request.set_body(request_uri.query())" seems to be the best way to get the formatted query text.

-evan

New Post: Incorrect POST format

October 9, 2015, 11:33 am

≫ Next: Created Unassigned: http listener not listening on "invalid" uri's [427]

≪ Previous: New Post: Incorrect POST format

$

0

0

Correct, this behavior is different for HTTP GET and HTTP POST requests.
The HTTP GET request method is designed to retrieve information from the server. As part of a GET request, some data can be passed within the URL's query string. As part of a POST request, an arbitrary amount of data of any type can be sent to the server in the body of the request message.

Glad you got it working!

Thanks
Kavya

Created Unassigned: http listener not listening on "invalid" uri's [427]

October 9, 2015, 12:31 pm

≫ Next: New Post: http listener not listening on "invalid" uri's

≪ Previous: New Post: Incorrect POST format

$

0

0

Hey Guys,

I'm using the listener on localhost and nearly everything works smoothly, but during testing I now ran into a problem. Whenever I'm trying to access the listener through in invalid uri scheme, the listener isn't notified about my request and therefore nothing happens.

In particular I'm trying to request the uri
```
http://localhost:7070/endpoint?id=[test]
```
unencoded and nothing happens! No response, no exception, nothing! Encoded as
```
http://localhost:7070/endpoint?id=%5Btest%5D
```
the request is noticed and correctly responded to.

Is this behaviour expected? If so, how is it possible to implement any service-sided feedback for requests on invalid uri's or is any client always responsible for ensuring the uri being valid?

Thanks in advance,
Frederic

New Post: http listener not listening on "invalid" uri's

October 9, 2015, 12:31 pm

≫ Next: New Post: http listener not listening on "invalid" uri's

≪ Previous: Created Unassigned: http listener not listening on "invalid" uri's [427]

$

0

0

This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.

New Post: http listener not listening on "invalid" uri's

October 9, 2015, 12:33 pm

≫ Next: New Post: URI's user info not used?

≪ Previous: New Post: http listener not listening on "invalid" uri's

$

0

0

hey FredericSt

This looks like a bug in our http_listener. We are not passing the request to the handler in such cases.
I have opened a workitem for this. However we may not be able to get to it in the near future.

Thanks
Kavya

New Post: URI's user info not used?

October 9, 2015, 3:10 pm

≫ Next: Commented Unassigned: Crash in tasks when calling http_client.request() on Linux. [420]

≪ Previous: New Post: http listener not listening on "invalid" uri's

$

0

0

I am attempting to communicate with a Web service that expects a user name and password in the URL (e.g., HTTP://username:password@domain.top). I'm supplying user info in the base URL, but it's not being sent that I can see. Further, I see no code in the Casablanca project that would send it. No code other than uri_builder and uri class manipulation calls uri_builder::user_info().

Does Casablanca, in fact, make no use of these data? If so, what can I do to work around this omission?

-evan

---

Commented Unassigned: Crash in tasks when calling http_client.request() on Linux. [420]

October 11, 2015, 1:07 am

≫ Next: New Post: TLS for http_listener

≪ Previous: New Post: URI's user info not used?

$

0

0

I've added Casablanca to an application I'm building that works on Windows and Linux. When I have Casablanca send REST requests to our server on Windows, everything works fine and I don't get any crash. However, on Linux the application runs but crashes anytime I try to send a request with Casablanca and I'm not sure why. It appears to be some kind of memory corruption due to bad strings, but I'm having difficulty figuring out what's going wrong. Note that the exact same code works fine on Windows - the only difference is that Windows uses wide strings and Linux doesn't (due to Casablanca's restriction here).

Here's the code I'm using (all are my files):

RestClient.h
```
private:
/// <summary>
/// The internal client used to send REST requests (Casablanca).
/// </summary>
web::http::client::http_client m_client;
```

RestClient.cpp
```
// Server root URL is a std::string that points to my server.
RestClient::RestClient(const LamaString& serverRootUri)
: m_client(serverRootUri)
{
}

HttpResponse RestClient::Get(const LamaString& url)
{
http_request request = BuildStandardHttpRequest(url, methods::GET);
return Send(request);
}

http_request RestClient::BuildStandardHttpRequest(
const LamaString& url,
const LamaString& method)
{
http_request request(method);

uri_builder builder(url);
request.set_request_uri(builder.to_uri());
request.headers().add(header_names::accept, U("application/json"));

request.headers().add(U(APPLICATION_ID_HTTP_HEADER), U(APPLICATION_ID));

request.headers().add(U(MACHINE_ID_HTTP_HEADER), U(MACHINE_ID));

return request;
}

HttpResponse RestClient::Send(http_request request)
{
// This call is where the memory corruption occurs, it stops program execution here on Linux.
task<http_response> task = m_client.request(request);
return HttpResponse();
}
```

Here's the error I'm getting in Eclipse:
malloc(): memory corruption: 0x0000000001b17c10 ***

Here's the call stack I'm seeing:
```
__GI_raise() at raise.c:56 0x7ffff2b99cc9
__GI_abort() at abort.c:89 0x7ffff2b9d0d8
__libc_message() at libc_fatal.c:175 0x7ffff2bd6394
malloc_printerr() at malloc.c:4,996 0x7ffff2be3f36
_int_malloc() at malloc.c:3,447 0x7ffff2be3f36
__GI___libc_malloc() at malloc.c:2,891 0x7ffff2be57b0
operator new() at 0x7ffff34a2dad
__gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<web::http::details::_http_response, std::allocator<web::http::details::_http_response>, (__gnu_cxx::_Lock_policy)2> >::allocate at new_allocator.h:104 0x7ffff4dff162
std::allocator_traits<std::allocator<std::_Sp_counted_ptr_inplace<web::http::details::_http_response, std::allocator<web::http::details::_http_response>, (__gnu_cxx::_Lock_policy)2> > >::allocate at alloc_traits.h:351 0x7ffff4dfe518
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<web::http::details::_http_response, std::allocator<web::http::details::_http_response>> at shared_ptr_base.h:499 0x7ffff4dfd5f6
std::__shared_ptr<web::http::details::_http_response, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<web::http::details::_http_response>> at shared_ptr_base.h:957 0x7ffff4dfc4b0
std::shared_ptr<web::http::details::_http_response>::shared_ptr<std::allocator<web::http::details::_http_response>>() at shared_ptr.h:316 0x7ffff4df9a50
std::allocate_shared<web::http::details::_http_response, std::allocator<web::http::details::_http_response>>() at shared_ptr.h:598 0x7ffff4df66f0
std::make_shared<web::http::details::_http_response>() at shared_ptr.h:614 0x7ffff4df2fb1
web::http::http_response::http_response() at http_msg.h:391 0x7ffff4df0da0
pplx::details::_ResultHolder<web::http::http_response>::_ResultHolder() at pplxtasks.h:832 0x7ffff4e03dde
pplx::details::_Task_impl<web::http::http_response>::_Task_impl() at pplxtasks.h:2,412 0x7ffff4fab291
__gnu_cxx::new_allocator<pplx::details::_Task_impl<web::http::http_response> >::construct<pplx::details::_Task_impl<web::http::http_response><pplx::details::_CancellationTokenState*&, pplx::scheduler_ptr&> >() at new_allocator.h:120 0x7ffff4faac21
std::allocator_traits<std::allocator<pplx::details::_Task_impl<web::http::http_response> > >::_S_construct<pplx::details::_Task_impl<web::http::http_response><pplx::details::_CancellationTokenState*&, pplx::scheduler_ptr&> >() at alloc_traits.h:254 0x7ffff4fa9db9
std::allocator_traits<std::allocator<pplx::details::_Task_impl<web::http::http_response> > >::construct<pplx::details::_Task_impl<web::http::http_response><pplx::details::_CancellationTokenState*&, pplx::scheduler_ptr&> >() at alloc_traits.h:393 0x7ffff4fa8d72
std::_Sp_counted_ptr_inplace<pplx::details::_Task_impl<web::http::http_response>, std::allocator<pplx::details::_Task_impl<web::http::http_response> >, (__gnu_cxx::_Lock_policy)2>::_Sp_counted_ptr_inplace<pplx::details::_CancellationTokenState*&, pplx::scheduler_ptr&> at shared_ptr_base.h:399 0x7ffff4fa6916
__gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<pplx::details::_Task_impl<web::http::http_response>, std::allocator<pplx::details::_Task_impl<web::http::http_response> >, (__gnu_cxx::_Lock_policy)2> >::construct<std::_Sp_counted_ptr_inplace<pplx::details::_Task_impl<web::http::http_response>, std::allocator<pplx::details::_Task_impl<web::http::http_response> >, (__gnu_cxx::_Lock_policy)2><std::allocator<pplx::details::_Task_impl<web::http::http_response> > const, pplx::details::_CancellationTokenState*&, pplx::scheduler_ptr&> > at new_allocator.h:120 0x7ffff4fa4d65
std::allocator_traits<std::allocator<std::_Sp_counted_ptr_inplace<pplx::details::_Task_impl<web::http::http_response>, std::allocator<pplx::details::_Task_impl<web::http::http_response> >, (__gnu_cxx::_Lock_policy)2> > >::_S_construct<std::_Sp_counted_ptr_inplace<pplx::details::_Task_impl<web::http::http_response>, std::allocator<pplx::details::_Task_impl<web::http::http_response> >, (__gnu_cxx::_Lock_policy)2><std::allocator<pplx::details::_Task_impl<web::http::http_response> > const, pplx::details::_CancellationTokenState*&, pplx::scheduler_ptr&> > at alloc_traits.h:254 0x7ffff4fa2f45
std::allocator_traits<std::allocator<std::_Sp_counted_ptr_inplace<pplx::details::_Task_impl<web::http::http_response>, std::allocator<pplx::details::_Task_impl<web::http::http_response> >, (__gnu_cxx::_Lock_policy)2> > >::construct<std::_Sp_counted_ptr_inplace<pplx::details::_Task_impl<web::http::http_response>, std::allocator<pplx::details::_Task_impl<web::http::http_response> >, (__gnu_cxx::_Lock_policy)2><std::allocator<pplx::details::_Task_impl<web::http::http_response> > const, pplx::details::_CancellationTokenState*&, pplx::scheduler_ptr&> > at alloc_traits.h:393 0x7ffff4fa0286
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<pplx::details::_Task_impl<web::http::http_response>, std::allocator<pplx::details::_Task_impl<web::http::http_response> >, pplx::details::_CancellationTokenState*&, pplx::scheduler_ptr&> at shared_ptr_base.h:502 0x7ffff4f9e335
std::__shared_ptr<pplx::details::_Task_impl<web::http::http_response>, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<pplx::details::_Task_impl<web::http::http_response> >, pplx::details::_CancellationTokenState*&, pplx::scheduler_ptr&> at shared_ptr_base.h:957 0x7ffff4f9b1db
std::shared_ptr<pplx::details::_Task_impl<web::http::http_response> >::shared_ptr<std::allocator<pplx::details::_Task_impl<web::http::http_response> >, pplx::details::_CancellationTokenState*&, pplx::scheduler_ptr&>() at shared_ptr.h:316 0x7ffff4f9827e
std::allocate_shared<pplx::details::_Task_impl<web::http::http_response>, std::allocator<pplx::details::_Task_impl<web::http::http_response> >, pplx::details::_CancellationTokenState*&, pplx::scheduler_ptr&>() at shared_ptr.h:598 0x7ffff4f95972
std::make_shared<pplx::details::_Task_impl<web::http::http_response>, pplx::details::_CancellationTokenState*&, pplx::scheduler_ptr&>() at shared_ptr.h:614 0x7ffff4f9252d
pplx::details::_Task_ptr<web::http::http_response>::_Make() at pplxtasks.h:1,429 0x7ffff4f8e519
pplx::task<web::http::http_response>::_CreateImpl() at pplxtasks.h:3,630 0x7ffff4f89d3f
pplx::task<web::http::http_response>::task<pplx::task_completion_event<web::http::http_response> >() at pplxtasks.h:3,304 0x7ffff4f8e325
pplx::create_task<pplx::task_completion_event<web::http::http_response> >() at pplxtasks.h:4,726 0x7ffff4f89ba0
0x0
```

I also tried to reproduce the error directly by removing all Casablanca code except calling some of the task creation code directly like the library does internally. When I do this, I get another exception when attempting to destroy the _http_response internal structure. Note this snippet of code also works fine on Windows and doesn't crash. In this case I'm not passing strings of any kind to Casablanca and it's still crashing, so I'm not sure why this is.

Here's the small snippet I tried:
```
task_completion_event<http_response> e;
create_task(e);
```

Here's the callstack I get after the task goes out of scope (truncated due to character limit when posting):
Thread #1 [app] 20995 [core: 0] (Suspended : Signal : SIGSEGV:Segmentation fault)
__gnu_cxx::__exchange_and_add() at atomicity.h:49 0xba9942
__gnu_cxx::__exchange_and_add_dispatch() at atomicity.h:82 0xba99d7
std::string::_Rep::_M_dispose() at basic_string.h:246 0xbb21e0
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() at
...

Here's what the locals window shows on the string:
_M_p char * 0x1 <error: Cannot access memory at address 0x1>

Any help is appreciated!
Comments: Been digging into this for about 2 weeks now, so I may have to move on and use some other approach if I can't get this working. I'm getting all kinds of memory corruption problems anytime I use the http_request structure on Linux (or if the Casablanca library uses it at all). If I don't use that structure, there are no memory errors reported with Valgrind. I've tried creating a sample application that repros all the libraries includes, compiler flags, etc. that I use in my larger application but I've been unable to reproduce the problems in a sample app. Here's the larger application code (I trimmed usage of the Casablanca http_request object as much as I could). ``` int main(int argc, char* argv[]) { { // Comment out this line and no corruption will occur or be reported. http_request request = http_request(); } return 0; } ``` As you can see, I'm not even making a request. Simply creating this object with the default constructor and allowing it to go out of scope causes corruption problems. If I don't use Casablanca, no memory issues are reported and the application runs ok from what I can tell. From the Valgrind errors, the best guess I have is that some memory inside the http_request object is being freed more than once during destruction, but I'm not sure. Here's the Valgrind error: ==27256== Memcheck, a memory error detector ==27256== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==27256== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==27256== Command: ./src/application ==27256== Parent PID: 10633 ==27256== ==27256== Invalid write of size 8 ==27256== at 0x7FBFA99: std::unique_ptr<web::http::details::_http_server_context, std::default_delete<web::http::details::_http_server_context> >::~unique_ptr() (unique_ptr.h:185) ==27256== by 0x7FBEAF9: web::http::details::_http_request::~_http_request() (in /usr/lib/x86_64-linux-gnu/libcpprest.so.2.6) ==27256== by 0xD5ABAE: void __gnu_cxx::new_allocator<web::http::details::_http_request>::destroy<web::http::details::_http_request>(web::http::details::_http_request*) (new_allocator.h:124) ==27256== by 0xD5AB64: std::enable_if<std::allocator_traits<std::allocator<web::http::details::_http_request> >::__destroy_helper<web::http::details::_http_request>::value, void>::type std::allocator_traits<std::allocator<web::http::details::_http_request> >::_S_destroy<web::http::details::_http_request>(std::allocator<web::http::details::_http_request>&, web::http::details::_http_request*) (alloc_traits.h:281) ==27256== by 0xD5AB1A: void std::allocator_traits<std::allocator<web::http::details::_http_request> >::destroy<web::http::details::_http_request>(std::allocator<web::http::details::_http_request>&, web::http::details::_http_request*) (alloc_traits.h:405) ==27256== by 0xD5AA62: std::_Sp_counted_ptr_inplace<web::http::details::_http_request, std::allocator<web::http::details::_http_request>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() (shared_ptr_base.h:407) ==27256== by 0xC075CF: std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (shared_ptr_base.h:144) ==27256== by 0xC0670A: std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() (shared_ptr_base.h:546) ==27256== by 0xD58B11: std::__shared_ptr<web::http::details::_http_request, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() (shared_ptr_base.h:781) ==27256== by 0xD58B2B: std::shared_ptr<web::http::details::_http_request>::~shared_ptr() (shared_ptr.h:93) ==27256== by 0xD58B75: web::http::http_request::~http_request() (http_msg.h:790) ==27256== by 0xD5582E: main (application.cpp:706) ==27256== Address 0xf145888 is 168 bytes inside a block of size 392 free'd ==27256== at 0x4C2C171: operator delete(void*) (vg_replace_malloc.c:575) ==27256== by 0xD5AA39: std::_Sp_counted_ptr_inplace<web::http::details::_http_request, std::allocator<web::http::details::_http_request>, (__gnu_cxx::_Lock_policy)2>::~_Sp_counted_ptr_inplace() (shared_ptr_base.h:403) ==27256== by 0x7FC03E9: std::default_delete<web::http::details::_http_server_context>::operator()(web::http::details::_http_server_context*) const (unique_ptr.h:67) ==27256== by 0x7FBFA94: std::unique_ptr<web::http::details::_http_server_context, std::default_delete<web::http::details::_http_server_context> >::~unique_ptr() (unique_ptr.h:184) ==27256== by 0x7FBEAF9: web::http::details::_http_request::~_http_request() (in /usr/lib/x86_64-linux-gnu/libcpprest.so.2.6) ==27256== by 0xD5ABAE: void __gnu_cxx::new_allocator<web::http::details::_http_request>::destroy<web::http::details::_http_request>(web::http::details::_http_request*) (new_allocator.h:124) ==27256== by 0xD5AB64: std::enable_if<std::allocator_traits<std::allocator<web::http::details::_http_request> >::__destroy_helper<web::http::details::_http_request>::value, void>::type std::allocator_traits<std::allocator<web::http::details::_http_request> >::_S_destroy<web::http::details::_http_request>(std::allocator<web::http::details::_http_request>&, web::http::details::_http_request*) (alloc_traits.h:281) ==27256== by 0xD5AB1A: void std::allocator_traits<std::allocator<web::http::details::_http_request> >::destroy<web::http::details::_http_request>(std::allocator<web::http::details::_http_request>&, web::http::details::_http_request*) (alloc_traits.h:405) ==27256== by 0xD5AA62: std::_Sp_counted_ptr_inplace<web::http::details::_http_request, std::allocator<web::http::details::_http_request>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() (shared_ptr_base.h:407) ==27256== by 0xC075CF: std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (shared_ptr_base.h:144) ==27256== by 0xC0670A: std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() (shared_ptr_base.h:546) ==27256== by 0xD58B11: std::__shared_ptr<web::http::details::_http_request, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() (shared_ptr_base.h:781) Any thoughts on how I can debug this further or things I can try are appreciated - thanks!

New Post: TLS for http_listener

October 13, 2015, 6:05 am

≫ Next: New Post: TLS for http_listener

≪ Previous: Commented Unassigned: Crash in tasks when calling http_client.request() on Linux. [420]

$

0

0

Hello,

I have implemented http server on windows desktop. Now, I would I like to add TLS security for it. I could find solutions for http client on this forum, such as using WinHttp. But how to do this for http server?

PS: I am currently using C++ REST SDK 2010 because my company still uses VS10 compiler.

Thanks,

Abhijeet

New Post: TLS for http_listener

October 13, 2015, 10:47 am

≫ Next: New Post: http_listener multiple routes

≪ Previous: New Post: TLS for http_listener

$

0

0

Because we are using WinHttp for our implementation, it should 'just work'. With a little adaptation, the instructions here explain how to set up the certificate.

New Post: http_listener multiple routes

October 13, 2015, 1:27 pm

≫ Next: New Post: http_listener multiple routes

≪ Previous: New Post: TLS for http_listener

$

0

0

So multiple http_listener would be the correct way to handle routes?

for doing things similar to C#'s ASP.NET MVC


url/model/action/data
url/model/data

... etc?

New Post: http_listener multiple routes

October 13, 2015, 3:24 pm

≫ Next: New Post: Creating JSON arrays

≪ Previous: New Post: http_listener multiple routes

$

0

0

On Windows, yes you can use multiple http_listeners to handle routes this way.

However, on non-Windows systems, this probably will not work. You will need to manually dispatch inside your support callback.