• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

godfat / rest-core / 541

Build:
DEFAULT BRANCH: master
Ran 14 May 2017 03:31PM UTC
Jobs 5
Files 32
Run time 6min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

pending completion
541

push

travis-ci

godfat
Strip UTF-8 BOM properly in JsonResponse

* Whenever there's a header Content-Type: charset=utf-8, httpclient
  would tag the response as encoded in UTF-8, which is fine. However
  if that's not the case, for example, if that header was missing,
  httpclient would tag it as encoded in ASCII-8BIT, which cannot
  be compared to a UTF-8 encoded regular expression. Considering
  that an API might not have set the header, while still giving JSON
  encoded in UTF-8, we still need to strip the BOM for ASCII-8BIT,
  unless we want to force the encoding to UTF-8 beforehand.
  Instead of enforcing the encoding, we try to only remove the BOM
  for ASCII-8BIT against the same regular expression encoded in
  ASCII-8BIT, instead of doing so for all kinds of encoding, which
  would only happen whenever another charset was set, which we
  should trust and avoid changing the encoding. In those cases,
  we pass the response to the JSON parser directly, hoping that
  it would do the right thing for us.

* We also just pass the response if the body was not a String,
  hoping that it might support some streaming cases. This could
  somehow be considered a breaking change because we no longer
  try to convert the response to a String for you, but I hope
  no one is really depending on that behaviour, because it's not
  really the way it should be.

* Third breaking change. We no longer use the trick to wrap the
  response with an array and then unwrap it to make sure that
  it could parse things like "test". I just tested that in newer
  json gem, it could now parse "test" instead of complaining,
  and so forth for true and false and null. However, it would
  still complain for an empty string! In order to keep this
  compatibility, we would try to convert an empty string to null,
  so that json gem would still act like yajl, keeping the behaviour.
  Actually, this shouldn't really be a breaking change, because
  we tried hard to maintain the compatibility. It would only break
  for people using older json gem, which I hope no one is doing that.

See: https://github.com/godfat/rest-core/issues/24

587 of 648 relevant lines covered (90.59%)

38.51 hits per line

Jobs
ID Job ID Ran Files Coverage
1 541.1 (2.2.5, json_lib=json) 14 May 2017 03:31PM UTC 0
90.61
Travis Job 541.1
2 541.2 (2.2.5, json_lib=yajl) 14 May 2017 03:31PM UTC 0
90.61
Travis Job 541.2
3 541.3 (2.3.2, json_lib=json) 14 May 2017 03:31PM UTC 0
90.63
Travis Job 541.3
4 541.4 (2.3.2, json_lib=yajl) 14 May 2017 03:31PM UTC 0
90.63
Travis Job 541.4
7 541.7 (jruby-9, JRUBY_OPTS=--debug) 14 May 2017 03:37PM UTC 0
90.25
Travis Job 541.7
Source Files on build 541
Detailed source file information is not available for this build.
  • Back to Repo
  • Travis Build #541
  • 4123ca48 on github
  • Prev Build on master (#540)
  • Next Build on master (#542)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc