It is possible to write out corrupt tapes #52

Closed
robfletcher opened this Issue Apr 24, 2012 · 19 comments

Projects

None yet

3 participants

Collaborator

Some data. e.g. from this URL: http://blog.freeside.co/atom.xml will get written to tape in such a way that the tape cannot be read again. SnakeYAML seems to be at fault but need to confirm it's not something to do with custom dump/read code.

Collaborator

Defintely not SnakeYAML's fault. Example project using same data works fine. Betamax must be messing up the encoding somewhere. Possibly because the HTTP response doesn't declare a charset.

Managed to reproduce this when page responses are returning unicode characters.

If you run a tape against this url : http://d297h9he240fqh.cloudfront.net/cache-1633a825c/assets/views_one.css

You'll end up with some unicode characters that break the reading in of the tape.

This is a minimal tape with the code that jams up the tape reader.

!tape
name: rewards
interactions:
- recorded: 2012-07-16T23:53:06.409Z
  request:
    method: GET
    uri: http://d297h9he240fqh.cloudfront.net/cache-1633a825c/assets/views_one.css
    headers:
      Accept: '*/*'
      Accept-Language: en-us
      Host: d297h9he240fqh.cloudfront.net
      Proxy-Connection: Keep-Alive
      Referer: http://www.kickstarter.com/projects/1342319572/the-nifty-minidrive?ref=live
      User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
  response:
    status: 200
    headers:
      Accept-Ranges: bytes
      Age: '22629'
      Cache-Control: max-age=315360000
      Content-Type: text/css
      Date: Mon, 16 Jul 2012 17:35:53 GMT
      Expires: Thu, 14 Jul 2022 17:35:53 GMT
      Last-Modified: Fri, 13 Jul 2012 18:11:15 GMT
      Server: nginx/1.0.11
      X-Amz-Cf-Id: RTwcJb-feG_-JQO5VNNNCTncqlQljixy15UmGw6U4Geag8xI-GUW-w==,l7S1JHfoy9zAc92O7buOUH5dBH-eQ1_UeCRhg5-IEPHJU5Qx37XSAQ==
      X-Cache: Hit from cloudfront
    body: "dt:before{content:\"� \"}"
Collaborator

@tomaslin One thing I notice with that file is that there's no encoding specified in the response headers. What encoding is it supposed to be?

Collaborator

I think the problem is the following bit of code in Jetty's Response class:

    public String getCharacterEncoding()
    {
        if (_characterEncoding==null)
            _characterEncoding=StringUtil.__ISO_8859_1;
        return _characterEncoding;
    }

It assumes that any response with no declared charset is ISO-8859-1.

Collaborator

On further investigation it turns out that the servlet spec says the default charset is assumed to be ISO-8859-1 in the absence of anything in the Content-Type header. See http://docs.oracle.com/javaee/5/api/javax/servlet/ServletResponse.html#getCharacterEncoding()

The file @tomaslin linked to is actually UTF-8 from what I can tell, but since the server is not sending a charset on the Content-Type header Jetty assumes that it should be ISO-8859-1.

What's annoying is that SnakeYAML will happily write the corrupt data out in such a way that it can't read it back in again.

I've tried a couple of libraries to guess the charset without success:

  • Groovy's CharsetToolkit requires a File as input but even when I dump out the response body to a temp file it doesn't detect the charset correctly, I think because the multibyte character is fairly far into the file & that class just scans the first 4K.
  • ICU4J's CharsetDetector just throws ArrayIndexOutOfBoundsException when I try to use it. So much for a "mature" library.
Collaborator

An earlier version of ICU4J doesn't throw an exception but confidently declares the data is IBM420_ltr (conveniently not an encoding supported by InputStreamReader which Betamax later uses to translate the bytes to text). UTF-8 isn't even detected as a possibility.

Below is a tape where this issue seems to occur. I changed the URL and host from the request/response.
Hope it helps solving this issue.

!tape
name: tryoutTape
interactions:

  • recorded: 2012-08-28T13:39:56.358Z
    request:
    method: POST
    uri: http://ocsp.site.com/public/ocsp
    headers:
    Content-Length: '2251'
    Content-Type: application/ocsp-request
    Host: ocsp.site.com
    Proxy-Connection: Keep-Alive
    User-Agent: '_OCSP Client_'
    body: !!binary |-
    MO+/vQjvv70w77+976GB77+977977+9MO+/ve+/vTELMAkGA1UEBhMCUFQxHDAaBgNVBAoMTDo28gZGUgQ2lkYWTDo28xFDASBgNVBAsMC3N1YkVDRXN0YWRvMUEwPwYDVQQDDDgoVGVzdGUpIEVDIGRlIEF1dGVudGljYcOnw6NvIGRvIENhcnTDo28gZGUgQ2lkYWTDo28gMDAwMjBFMEMwQTAJBgUrDgMCGgUABBQOIDtt77+977+9RXDvv73vv73vv71hIO+/vWMXbQ1XVgQULu+/ve+/ve+/vXzvv70KTO+/ve+/ve+/ve+/vQQL77+977+9Aggp4Ze8Uu+/ve+/vSTvv70ZMBcwFQYJKwYBBQUHMAECBAge77+9QhXvv73vv71566CCB++/vTDvv70H77+9MA0GCSrvv71I77+977+9DQEBBQUAA++/ve+/vQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAe+/ve+/vQc2MO+/vQcyMO+/vQcuMO+/vQYW77+9AwIBAgIIKeGXvFLvv73vv70kMA0GCSrvv71I77+977+9DQEBBQUAMO+/ve+/vTFBMD8GA1UEAww4KFRlc3RlKSBFQyBkZSBBdXRlbnRpY2HDp8OjbyBkbyBDYXJ0w6NvIGRlvIDAwMDIxFDASBgNVBAsMC3N1YkVDRXN0YWRvMRwwGgYDVQQKDBNDYXJ0w6NvIGRlIENpZGFkw6NvMQswCQYDVQQGEwJQVDAeFw0wODEwMDkxNTM0NTlaFw0xMzA2MTkyMzAwMDBaMO+/ve+/vTEVMBMGA1UEAwwMQ2FybGEgVmFsaWRvMRMwEQYDVQQFEwpCSTk5MDAwMDA2MQ4wDAYDVQQqDAVDYXJsYTEPMA0GA1UEBAwGVmFsaWRvMSswKQYDVQQLDCIoVGVzdGUpIEF1dGVudGljYcOnw6NvIGRvIENpZGFkw6NvMRwwGgYDVQQLDBNDaWRhZMOjbyBQb3J0dWd1w6pzMRwwGgYDVQQKDBNDYXJ0w6NvIGRlIENpZGFkw6NvMQswCQYDVQQGEwJQVDDvv73vv70wDQYJKu+/vUjvv73vv70NAQEBBQAD77+977+9ADDvv73vv70C77+977+9AO+/vcq3E+977+9N++/ve+/vQnvv70J77+9E1Dvv71d77+9Ci/vv73vv73vv73vv70077+977+9Tu+/ve+/vXvvv70R77+9ERfvv70qX1Tvv71NMu+/ve+/ve+/ve+/vVI977+9a++/vdGp77+977+9DN6R77+9bXDvv70m77+9Z++/vRJyLe+/vcuO77+977+9FGrvv73vv704xKbvv73vv71m77+9Ge+/ve+/vciN45G077+977+9VO+/ve+/vQpLBihyYc6Z77+9Ie+/ve+/vUxVKe+/vQbvv70zAgMBAAHvv73vv70D77+9MO+/vQPvv70wDAYDVR0TAQHvv70EAjAAMA4GA1UdDwEB77+9BAQDAgPvv70wHQYDVR0OBBYEFD7vv73vv73vv70477+9zZ0ne++/vQpw77+9Hcaybu+/ve+/vTAfBgNVHSMEGDAW77+9FC7vv73vv73vv71877+9Ckzvv70dWyLvv73vv73vv73vv70EC++/ve+/vTDvv70CDwYDVR0gBO+/vQIGMO+/vQICMO+/ve+/vQYIYO+/vWwBAQECFDDvv73vv70w77+977+9BggrBgEFBQcCAjDvv73vv70e77+977+9AE8AIABjAGUAcgB0AGkAZgBpAGMAYQBkAG8AIABlAG0AaQB0AGkAZABvACAAcwBlAGcAdQBuAGQAbwAgAGUAcwB0AGEAIABwAG8AbADvv70AdABpAGMAYQAgAO+/vQAgAHUAdABpAGwAaQB6AGEAZABvACAAcABhAHIAYQAgAGEAdQB0AGUAbgB0AGkAYwBhAO+/vQDvv70AbwAgAGQAbwAgAEMAaQBkAGEAZADvv70AbzB+Bgtg77+9bAEBAQIEAgAHMG8wbQYIKwYBBQUHAgEWYWh0dHA6Ly9wa2kudGVzdGUuY2FydGjaWRhZGFvLnB0L3B1YmxpY28vcG9saXRpY2FzL2RwYy9jY19zdWItZWNfY2lkYWRhb19hdXRlbnRpY2FjYW9fZHBjLmh0bWwwNgYIYO+/vWwBAQECCjAqMCgGCCsGAQUFBwIBFhxodHRwOi8vd3d3LnNjZWUuZ292LnB0L3BjZXJ0MH0GDGDvv71sAQEBAgQCAAEBMG0wawYIKwYBBQUHAgEWX2h0dHA6Ly9wa2kudGVzdGUuY2FydGFvZGVjaWRhZGFvLnB0L3B1YmxpY28vcG9saXRpY2FzL3BjL2NjX3N1Yi1lY19jaWRhZGFvX2F1dGVudGljYWNhb19wYy5odG1sMGsGA1UdHwRkMGIwYO+/vV7vv71c77+9Wmh0dHA6Ly9wa2kudGVzdGUuY2FydGFvZGVjaWRhZGFvLnB0L3B1YmxpY28vbHJj1lY19jaWRhZGFvX2F1dGVudGljYWNhb19jcmwwMDAyLmNybDBxBgNVHS4EajBoMGbvv71k77+9Yu+/vWBodHRwOi8vcGtpLnRlc3RlLmNhcnRhb2RlY2lkYWRhby5wdC9wdWJsaWNvL2xyYy9jY19zdWItZWNfY2lkYWRhb19hdXRlbnRpY2FjYW9fY3JsMDAwMl9kZWx0YS5jcmwwUQYIKwYBBQUHAQEERTBDMEEGCCsGAQUFBzAB77+9NWh0dHA6Ly9vY3NwLmF1Yy50ZXN0ZS5jYXJ0YW9kZWNpZGFkYW8ucHQvcHVibGljby9vY3NwMBEGCWDvv71IAe+/ve+/vUIBAQQEAwIA77+9MCgGA1UdCQQhMB8wHQYIKwYBBQUHCQExERgPMTk3NDA1MTAxMjAwMDBaMA0GCSrvv71I77+977+9DQEBBQUAA++/vQEBAO+/vRjvv73vv73vv71D77+9K++/vUTvv73vv73vv73vv71fYkfvv73vv70l77+9Ye+/vQ7vv73vv73vv73vv71I77+977+977+9J++/vV/ve+/vWx+bu+/vWHvv71I77+977+977+977+9De+/vXbvv73vv73vv70/77+977+9ZE3vv70s77+977+9xqYrPO+/vTnvv73vv70xPDTNix3vv73vv71977+977+9Du+/vWbvv70E77+91b3vv73vv70X5oOjB0nvv71H77+9de+/ve+/vU0k77+9SO+/vVpSaVILf9C1eO+/ve+/vR3vv73vv73vv718Uu+/ve+/ve+/vQQHdO+/vTkUAClFHe+/vSl0T2EA77+977+977+9edq8QALvv73UkTHvv73vv70c77+9C1MdxZzvv70ZeSTvv71SWu+/vU1ZGO+/vXXvv71ZfwDvv71IdO+/ve+/vVs/77+977+977+977+9hrS5u77+9Q2Hvv71iFu+/ve+/vWbvv73vv71877+977+9QO+/vVMA77+9FVDvv73vv73vv73vv71H77+977+9Ru+/vQPvv73vv73vv718zpVd77+9Xu+/vV3vv70=
    response:
    status: 200
    headers:
    Cache-Control: max-age=120
    Content-Type: application/ocsp-response
    Date: Tue, 28 Aug 2012 13:39:56 GMT
    Expires: Tue, 28 Aug 2012 13:41:56 GMT
    Server: Apache
    Set-Cookie: JSESSIONID=1BBC8B82760C3371C8D40BD67116D171; Path=/
    X-Cache: MISS from bproxy.enterprise.inet
    X-Cache-Lookup: MISS from bproxy.enterprise.inet:8080
    X-Powered-By: 'Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5'
    body: !!binary |-
    MIIJ3QoBAKCCCdYwggnSBgkrBgEFnDMIIJvzCCAXOhgeowgecxcTBvBgNVBAMMaChUZXN0ZSkgU2VydmnDp28gZGUgVmFsaWRhw6fDo28gb24tbGluZSBkbyBDYXJ0w6NvIGRlIENpZGFkw6NvIDAwMDAwNSAtIEVDIGRlIEF1dGVudGljYcOnw6NvIGRvIENpZGFkw6NvMRwwGgYDVQQLDBNWYWxpZGHDp8OjbyBvbi1saW5lMSkwJwYDVQQLDCBTZXJ2acOnb3MgZG8gQ2FydMOjbyBkZSBDaWRhZMOjbzEcMBoGA1UECgwTQ2FydMOjbyBkZSBDaWRhZMOjbzELMAkGA1UEBhMCUFQYDzIwMTIwODI4MTMzOTU2WjBYMFYwQTAJBgUrDgMCGgUABBQOIDttkctFcI/s8mEgwGMXbQ1XVgQULt7N2nz1CkySHVsijcCf4QQLyMACCCnhl7xSlIQkgAAYDzIwMTIwODI4MTMzOTU2WqEZMBcwFQYJKwYBBQUHMAECBAgeoUIV5dF56zAJBgUrDgMCHQUAA4IBAQCZtSuLrFsjqUCXYFcpqgCPGLa9JmFDPRTthJh/7GYOrfnjzbzIecpiZJygfsDsodhk6tlIC/fCxUILkmtsUOPpCaOGdv7OkWPPXyRPe1kyux/HehiglyjlU0awMe/z335TEzQLdAMqx9xnNm9q63sDosEndh42cTfHMGwK0/dy+WLwHgP5B6bPmSHXVKxthXrEVsfXo9nDdi/I1SkIZZ/VoUX22FcXfovYyKCv1zWVLa9+VBcREshy8rb8bJEinWB1tOAf17aunYMMFz6ajDPcod/k9bNLpnp9YUPQna7AtnyQTZ8aqTDdnCJkAurNdydJu3nSUBroIIHNDCCBzAwggcsMIIGFKADAgECAggSwXI/LsIR1DANBgkqhkiG9w0BAQUFADCBhDFBMD8GA1UEAww4KFRlc3RlKSBFQyBkZSBBdXRlbnRpY2HDp8OjbyBkbyBDYXJ0w6NvIGRlIENpZGFkw6NvIDAwMDIxFDASBgNVBAsMC3N1YkVDRXN0YWRvMRwwGgYDVQQKDBNDYXJ0w6NvIGRlIENpZGFkw6NvMQswCQYDVQQGEwJQVDAeFw0xMjA1MTYxMDQyMzhaFw0xNzA3MjkxMDUyMzhaMIHnMXEwbwYDVQQDDGgoVGVzdGUpIFNlcnZpw6dvIGRlIFZhbGlkYcOnw6NvIG9uLWxpbmUgZG8gQ2FydMOjbyBkZSBDaWRhZMOjbyAwMDAwMDUgLSBFQyBkZSBBdXRlbnRpY2HDp8OjbyBkbyBDaWRhZMOjbzEcMBoGA1UECwwTVmFsaWRhw6fDo28gb24tbGluZTEpMCcGA1UECwwgU2VydmnDp29zIGRvIENhcnTDo28gZGUgQ2lkYWTDo28xHDAaBgNVBAoME0NhcnTDo28gZGUgQ2lkYWTDo28xCzAJBgNVBAYTAlBUMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzlYWGLpgTGseFcwteXr9eSFuayCZXIqfULHlMQW5xe/lewamqHat+2bBtrZtO4kj7vZpRSeHWFS2XW8T5nZ2kf85p/wIV/DYVmJ9UrZ/Em1cT6abAkRuYIEM3U/9fQZ53amiiwdKcQdwfYxexRZOOrf2Dyl/YLnE8IJLcCAtX/rPQNL/xYzGNgL4HL4CX/f+md7DQPbL30zn87JmGA5O5F7V/i1RHu0fkDSwp1oe353InyLF0Mq2QeHVdvJkSu32wd3uMnn10kZ4ySFuGP2dujqww8PyrHxCOiGsmsJH3LfDtAvxH+OjQHYNSzFlav5nbu7s3+o8nxidhSQIDAQABo4IDOzCCAzcwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwEwYDVR0lBAwwCgYIKwYBBQUHAwkwHQYDVR0OBBYEFHoiK1QMOUafJoEid/Q4eZTny1ODMB8GA1UdIwQYMBaAFC7ezdp89QpMkh1bIo3An+EEC8jAMIIBfAYDVR0gBIIBczCCAW8wgewGDGCEbAEBAQIEAgABAjCB2zCB2AYIKwYBBQUHAgIwgcsegcgAaAB0BwAGsAaQAuAHQAZQBzAHQAZQAuAGMAYQByAHQAYQBvAGQAZQBjAGkAZABhAGQAYQBvAC4AcAB0AC8AcAB1AGIAbABpAGMAbwAvAHAAbwBsAGkAdABpAGMAYQBzAC8AcABjAC8AYwBjAF8AcwB1AGIALQBlAGMAXwBjAGkAZABhAGQAYQBvAF8AYQB1AHQAZQBuAHQAaQBjAGEAYwBhAG8AXwBPAEMAUwBQAF8AcABjAC4AaAB0AG0AbDB+BgtghGwBAQECBAIABzBvMG0GCCsGAQUFBwIBFmFnRlc3RlLmNhcnRhb2RlY2lkYWRhby5wdC9wdWJsaWNvL3BvbGl0aWNhcy9kcGMvY2Nfc3ViLWVjX2NpZGFkYW9fYXV0ZW50aWNhY2FvX2RwYy5odG1sMGsGA1UdHwRkMGIwYKBeoFyGWmh0dHA6Ly9wa2kudGVzdGUuY2FydGFvZGVjaWRhZGFvLnB0L3B1YmxpY28vbHJjL2NjX3N1Yi1lY19jaWRhZGFvX2F1dGVudGljYWNhb19jcmwwMDAyLmNybDBxBgNVHS4EajBoMGagZKBihmBodHRwOi8vcGtpLnRlc3RlLmNhcnRhb2RlY2lkYWRhby5wdC9wdWJsaWNvL2xyYy9jY19zdWItZWNfY2lkYWRhb19hdXRlbnRpY2FjYW9fY3JsMDAwMl9kZWx0YS5jcmwwUQYIKwYBBQUHAQEERTBDMEEGCCsGAQUFBzABhjVodHRwOi8vb2NzcC5hdWMudGVzdGUuY2FydGFvZGVjaWRhZGFvLnB0L3B1YmxpY28vb2NzcDAPBgkrBgEFBQcwAQUEAgUAMA0GCSqGSIb3DQEBBQUAA4IBAQBDRBVfzAzfFiQNa/sIz+mxH8X0b6wk1x0Mjs7tPavUNs2jU4xFc6rhIlOqqYqYSFYlcC3uBQpjy/ihi9z1f1HVoXi1KTmD3bYc52Mq1JctQ69dzhgysvwduCLl/tOc4itSEh43ZymrtqZ7eYLVd9uIssXwRW9a5epryBUh/DHIpVEiytRz4sByAAGuCwJmq+FkMT0BDVRrhRMx7MQjHbQDeGS1ASb1pUFNWswRFTHiCGW2tqpR5ANT5xVhcioK9zzJx1+pVrJ6XYDA5HQy5EFGtmhyaQ90yWqSuVgnEEnb+nIpW2aPG1kRci/PN/amhXgddVCxB
Collaborator

@tiagobizzy I think that tape data might be truncated. I guess comments are limited to a maximum size.

I notice that some bytes are missing from the binary data, but the tapes ends with that final bytes. It has also lost formatting. Sorry. Do you want me to send it to you in another way?

Collaborator

Yeah, if you can send it as an attachment that would be great

On 29 Aug 2012, at 10:28, tiagobizzy notifications@github.com wrote:

I notice that some bytes are missing from the binary data, but the tapes
ends with that final bytes. It has also lost formatting. Sorry. Do you want
me to send it to you in another way?


Reply to this email directly or view it on
GitHubhttps://github.com/robfletcher/betamax/issues/52#issuecomment-8119792.

Hope it helps.

Thanks.

On Wed, Aug 29, 2012 at 10:30 AM, Rob Fletcher notifications@github.comwrote:

Yeah, if you can send it as an attachment that would be great

On 29 Aug 2012, at 10:28, tiagobizzy notifications@github.com wrote:

I notice that some bytes are missing from the binary data, but the tapes
ends with that final bytes. It has also lost formatting. Sorry. Do you
want
me to send it to you in another way?


Reply to this email directly or view it on
GitHub<
https://github.com/robfletcher/betamax/issues/52#issuecomment-8119792>.


Reply to this email directly or view it on GitHubhttps://github.com/robfletcher/betamax/issues/52#issuecomment-8119846.

Tiago Filipe Martins
http://about.me/tiagomartins

Collaborator

@tiagobizzy I'm not seeing anything attached there

I sent it attached by mail. How should I send it, then?

On Thu, Aug 30, 2012 at 11:34 PM, Rob Fletcher notifications@github.comwrote:

@tiagobizzy https://github.com/tiagobizzy I'm not seeing anything
attached there


Reply to this email directly or view it on GitHubhttps://github.com/robfletcher/betamax/issues/52#issuecomment-8177050.

Tiago Filipe Martins
http://about.me/tiagomartins

Collaborator

Hmm, I think I got the mail via GitHub which had stripped the attachement
off. Can you email it direct to robert.w.fletcher@gmail.com

Thanks

On Fri, Aug 31, 2012 at 10:25 AM, tiagobizzy notifications@github.comwrote:

I sent it attached by mail. How should I send it, then?

On Thu, Aug 30, 2012 at 11:34 PM, Rob Fletcher notifications@github.comwrote:

@tiagobizzy https://github.com/tiagobizzy I'm not seeing anything
attached there


Reply to this email directly or view it on GitHub<
https://github.com/robfletcher/betamax/issues/52#issuecomment-8177050>.

Tiago Filipe Martins
http://about.me/tiagomartins


Reply to this email directly or view it on GitHubhttps://github.com/robfletcher/betamax/issues/52#issuecomment-8186769.

Collaborator

There's a further problem here. I've noticed that when Betamax's tests are running in IntellliJ IDEA some additional ones fail from when run from the terminal using Gradle. It seems the difference is that in the former case the file.encoding system property is set to UTF-8 and in the latter (on my machine) it's MacRoman.

I think somewhere I must be allowing the default charset to be used probably with an InputStreamReader and it's causing some corruption when the byte stream does not conform to the assumed charset.

Collaborator

Finally getting somewhere with this bug.

SnakeYaml 1.11-SNAPSHOT has fixed the bug where mis-encoded dumped data could not be read back. It now forces binary if non-printable characters are present in a string. However Betamax still has a problem as the bytes would then be written post-unzipping. When the tape is read back Betamax sees the Content-Encoding header and tries to unzip the body only to find it's not a valid gzip stream.

I can get round this by simply pre-empting the check SnakeYaml does for non-printable characters and dumping the raw byte stream of the response (i.e. the gzipped bytes) if any are detected. This fixes the handling of @tomaslin's weird CSS file although it will end up as binary data in the tape file which means it can't be easily manipulated by hand. I'm not too concerned about that, though as it's hopefully quite an edge case.

It's possible that implementing #59 might provide a better solution altogether as Betamax could effectively ignore the bytes altogether (apart from unzipping the stream). However, this still needs to be fixed as #59 should be optional.

There are a couple of wrinkles to work out but I should be able to commit a fix for this very soon.

@robfletcher robfletcher pushed a commit that referenced this issue Sep 12, 2012
Rob Fletcher #52 in-progress changes to charset handling 2df1b73

This means the issues I had with the tapes are also solved?

Collaborator

@tiagobizzy I suspect that's actually a separate issue. I'm going to investigate later & if it's still occurring open a new issue. This problem was specifically around character data whereas yours is all binary.

@robfletcher robfletcher pushed a commit that referenced this issue Sep 19, 2012
Rob Fletcher test to cover issue with OCSP data on tape
See comments by @tiagobizzy on #52

This seems to work fine following the refactor.
e1c4378
Collaborator

@tiagobizzy Looks like this is working fine now. See e1c4378

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment