2.0.0 Release is Live!

Coordinator
Mar 21 at 12:25 AM
Our next release, versioned 2.0.0 due to a couple of break changes is now live in the master branch and on the NuGet gallery.

Try it out and let us know! More details about the changes and new features can be found in the release notes.
Mar 22 at 8:50 PM
I see tests fail on master branch on mac os x.

using Xcode from apple app store:
clang++ --version
Apple LLVM version 5.1 (clang-503.0.9) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix

I use brew to install openssl, boost, etc.

Should I worry:
**** connections_and_errors:server_doesnt_exist FAILED ****

**** connections_and_errors:open_failure FAILED ****

**** connections_and_errors:server_close_without_responding FAILED ****

**** connections_and_errors:request_timeout FAILED ****

**** connections_and_errors:invalid_method FAILED ****

**** connections_and_errors:handshake_fail FAILED ****

**** connections_and_errors:content_ready_timeout FAILED ****

**** progress_handler_tests:set_progress_handler_open_failure FAILED ****

**** request_stream_tests:get_with_body_nono FAILED ****

**** response_extract_tests:extract_string_incorrect FAILED ****

**** response_extract_tests:extract_json_incorrect FAILED ****

**** response_extract_tests:set_stream_try_extract_json FAILED ****

**** response_extract_tests:set_stream_try_extract_vector FAILED ****

**** response_stream_tests:set_response_stream_producer_consumer_buffer FAILED ****

**** response_stream_tests:set_response_stream_container_buffer FAILED ****

**** connections_and_errors:reply_twice FAILED ****

**** connections_and_errors:close_stream_early_with_length FAILED ****

**** connections_and_errors:close_stream_with_exception FAILED ****

**** reply_helper_tests:multiple_responses_to_request FAILED ****

**** construction_tests:array_test FAILED ****

**** construction_tests:object_test FAILED ****

**** negative_parsing_tests:string_t FAILED ****

**** negative_parsing_tests:numbers FAILED ****

**** negative_parsing_tests:objects FAILED ****

**** negative_parsing_tests:arrays FAILED ****

**** negative_parsing_tests:literals_not_lower_case FAILED ****

**** negative_parsing_tests:incomplete_literals FAILED ****

**** negative_parsing_tests:exception_string FAILED ****

**** negative_parsing_tests:boundary_chars FAILED ****

**** negative_parsing_tests:garbage_1 FAILED ****

**** negative_parsing_tests:garbage_2 FAILED ****

**** negative_parsing_tests:garbage_3 FAILED ****

**** parsing_tests:whitespace FAILED ****

**** parsing_tests:string_t FAILED ****

**** parsing_tests:comments_string FAILED ****

**** parsing_tests:comments_stream FAILED ****

**** parsing_tests:deeply_nested FAILED ****

**** to_as_and_operators_tests:as_string FAILED ****

**** to_as_and_operators_tests:negative_index_operator_boolean FAILED ****

**** to_as_and_operators_tests:negative_get_field_object FAILED ****

**** to_as_and_operators_tests:negative_get_element_array FAILED ****

**** to_as_and_operators_tests:negative_as_tests FAILED ****

**** iterator_tests:non_composites_member_preincrement FAILED ****

**** constructor_tests:parsing_constructor_invalid FAILED ****

**** encoding_tests:decode_invalid_hex FAILED ****

**** uri_builder_tests:to_string_invalid_uri FAILED ****

Finished running all 592 tests.
Took 11147.5ms
Coordinator
Mar 25 at 4:02 PM
Edited Mar 25 at 4:04 PM
Hi eskech!

I'd like to follow up with any issues you're having on OS X. I've copied your message into an issue so we can discuss further.

-- Automatic message --

This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Mar 25 at 7:49 PM
Hey, I'm building a Windows Store app.
I see C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1\ExtensionSDKs\CppRESTWindowsSDK has v1.0, but not v2.0.

Where can I find v2.0 of the "C++ REST Extension SDK for Windows Store apps"?
Should I just build it myself using "casablanca120.WinRT.sln"?

Thanks,
Jason
Coordinator
Mar 25 at 9:19 PM
Hi Jason,

Yes starting with our 2.0.0 release we only include a NuGet package. You could build Casablanca yourself and setup the includes/libs/dlls, but you should instead use our NuGet package.

Take a look at the instructions here on how to setup and use Casablanca with NuGet. If you are new to Casablanca I highly recommend you get started by following this simple Http client tutorial.

Let us know if you have any further questions.

Thanks,
Steve
Mar 29 at 11:56 PM
Edited Mar 30 at 12:11 AM
Having trouble with the NuGet package. I get a ton of link errors for unresolved external symbols for anything in the REST SDK. It looks like adding the nugget package adds the appropriate include paths but doesn't ensure the lib is linked in.

Edit: Nevermind, I had my tools configured to use the 2013 November CTP version. I'll either need to witch back to 2013 RTM or build Casablanca from source.
Coordinator
Mar 30 at 10:04 PM
Hi John,

Yes we are only supporting VS 2012 RTM and VS 2013 RTM and their respective updates. Let us know if you any other issues.

Steve
Mar 31 at 9:20 PM
Just one other known issue discussed in this thread:

http://casablanca.codeplex.com/discussions/470503

and tracked by this issue:

https://casablanca.codeplex.com/workitem/80

Between the CTP and this issue I decided that it would be worth looking into building from source anyway. I have not actually tried to build using the CTP yet, but I did dig into the bug a little bit. Based on the description of the issue and the actual behavior, it looks like the http callback handling in http_win7.cpp is being a little overly aggressive about considering the request done. There's a code block:
                    bool has_cnt_length = response.headers().match(header_names::content_length, content_length);
                    bool has_xfr_encode = response.headers().match(header_names::transfer_encoding, transfer_encoding);

                    // Determine if there is a msg body that needs to be read
                    bool hasMsgBody = (has_cnt_length && (content_length > 0)) || (has_xfr_encode);

                    if (!hasMsgBody)
                    {
                        auto progress = p_request_context->m_request._get_impl()->_progress_handler();
                        if ( progress )
                        {
                            try { (*progress)(message_direction::download, 0); } catch(...)
                            {
                                p_request_context->report_exception(std::current_exception());
                                return;
                            }
                        }

                        p_request_context->complete_request(0);
                        return;
                    }

                    // HTTP Specification states:
                    // If a message is received with both a Transfer-Encoding header field 
                    // and a Content-Length header field, the latter MUST be ignored.

                    // At least one of them should be set
                    _ASSERTE(has_xfr_encode || has_cnt_length);
I don't know the history of the code well enough to know the correct fix for this, but it looks like it might be best to not try to early out and to go ahead and always try to read data. I was able to make things work simply by commenting the quoted block out entirely, without running into errors. I'm not sure if this is the approach you want to take, or whether you want to refine the early out to allow it to succeed in a narrow set of cases, or maybe tie actual close to the WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING notification (which currently does nothing because it's expected that any request would already have been completed.

If there's a known edge case which will cause such a change to exhibit bad behavior, that would be great to know. Also, if I run into any issues compiling with the CTP, I'll be sure to pass them on. Even if you never support the CTP (which is fine, it's not supposed to be used for production code anyway) it might give you a heads up on stuff that'll break under VC13.
Coordinator
Mar 31 at 9:31 PM
Hi John,

Yes you are correct. We actually are planning a bug fix only release (2.0.1) shortly and it includes a fix for this case. Basically it was a case in the specification that we initially overlooked when implementing and is not that common in practice.

Steve