Unable to have a double receive any non-text body

[trackness]

Hello,

I'm unable to send any non-text-based body to an active double, and am unsure as to whether this is by design, or due to error on my behalf.

My Gemfile is as follows:

source 'https://rubygems.org' do
  gem 'rest-assured'
  gem 'rest-client'
  gem 'rubocop'
  gem 'sqlite3' # for rest-assured
end

Steps are as follows:

Given('a {string} cdn') do |destination|
  @full_path = "/#{destination}"
  @ra_destination = RestAssured::Double.create(
      :fullpath => @full_path,
      :verb => 'POST'
  )
  expect(@ra_destination.status).to eq(200)
end

Note the Then is sending a request to simulate the activity of the accompanying java application:

Then('{string} is received at {string}') do |file, uri|
file = File.read("#{CUCUMBER_DIR}/fixtures/#{chunk_name}")
RestClient.post(
    "localhost:4578#{@full_path}#{uri}",
    file,
    :content_type => 'video/mp4',
  )
  requests = @ra_destination.reload.requests
  expect(requests.first.body).to eq(file)
  expect(JSON.parse(requests.first.rack_env)['REQUEST_METHOD']).to eq('POST')
  expect(JSON.parse(requests.first.rack_env)['CONTENT_TYPE']).to eq('video/mp4')
  expect(JSON.parse(requests.first.rack_env)['REQUEST_URI']).to eq("#{@full_path}#{uri}")

This results in the fourth expect failing, with the top several stack trace line being:

2019-11-18 09:34:57 - Encoding::UndefinedConversionError - "\xC0" from ASCII-8BIT to UTF-8:
	/usr/local/lib/ruby/gems/2.6.0/gems/activerecord-5.2.3/lib/active_record/connection_adapters/sqlite3/quoting.rb:56:in `encode'
	/usr/local/lib/ruby/gems/2.6.0/gems/activerecord-5.2.3/lib/active_record/connection_adapters/sqlite3/quoting.rb:56:in `_type_cast'

Setting the POST body (and expected requests.body.first to be an arbitrary string causes the test to pass. Note also that this error is also seen when sending a valid curl from the terminal to a live double.

Please advise, thank you.

[artemave]

This looks like a missing feature - binary content that is. The error you see looks like an active record error due to the fact that it is trying to store binary data into the text field.

We could change rest-assured to store everything as binary and convert it to text on the way in/out for textual content_types. And NOT convert for video/mp4 (and similar)

[trackness]

Thanks for the answer and clarity. Is that an avenue you would consider following in the very immediate future?

[artemave]

I can't promise you to get on it soon. But I am generally quick with accepting pull requests :)

[PyvesB]

We could change rest-assured to store everything as binary and convert it to text on the way in/out for textual content_types. And NOT convert for video/mp4 (and similar)

I've had a quick look into this. Storing everything as binary data is quite easy (I came up with a DB migrate file that takes care of this), however REST-assured converts request objects to JSON when responding to the /doubles/:id.json endpoint:

REST-assured/lib/rest-assured/routes/double.rb

Line 37 in 6b716c8

body double.to_json(:include => :requests)

This won't work with binary data. Not sure whether there's a nice trick we could do to workaround the problem.

Another approach would be to return binary data as Base64 strings, however Ruby code that integrates with this Gem needs to explicitly decode it, which is not ideal.

[artemave]

Another approach would be to return binary data as Base64 strings, however Ruby code that integrates with this Gem needs to explicitly decode it, which is not ideal.

I see. Well, it's a bit of an edge case, so maybe that's ok? What code needs to examine the double body anyway? I can only think of web ui that comes with the gem.

[PyvesB]

I see. Well, it's a bit of an edge case, so maybe that's ok? What code needs to examine the double body anyway? I can only think of web ui that comes with the gem.

Actually the bit of code I linked seems to be run each time something like @double.reload is called, so it's not just the Web UI.

[artemave]

Yeah fair enough. Though the purpose of reload is to assert requests, not to check on the double payload - it is likely being set just a few lines above in the test script.