Closed paulspencerwilliams closed 10 years ago
Oh interesting! So the cassette contents is definitely encrypted, not merely a base-64 encoding of the plaintext?
I think figuring this out requires determining how clj-http handles https. It looks like it happens at a low level.
vcr-clj is just treating clj-http.core/request as an opaque function, recording its inputs/outputs. So the main question is how clj-http's handling of HTTPS relates to that function.
Had presumed the files contents where encrypted - hadn't checked. I agree with your assumption that clj-http's function would just return un-encrpyted content, but obviously we're wrong.
Can I help in any way?
I can't naively reproduce this. What I tried:
(ns user
(:require [clj-http.client :as client]
[vcr-clj.clj-http :refer [with-cassette]]))
;; first time, records actual http call
(def body1 (:body (with-cassette "foo" (client/get "https://google.com"))))
;; second time, uses cassette
(def body2 (:body (with-cassette "foo" (client/get "https://google.com"))))
;; returning true indicates to me this is working correctly
(= body1 body2)
;; => true
Can you verify that you get the same result, and describe how what you're doing is different from this?
Hi fredericksgary,
Firstly,
When I run your code in the repl, all three lines execute but with unexpected output if you println body1 / body2
Body1 - from actually http request shows full html (shortened in this example:
<!doctype html><html itemsco...here.
I've successfully used cartridge to record and playback plain http traffic. However, when I try to record and playback encrypted https traffic, (json in my case), data from the resultant playback is invalid - I believe encrypted. Certainly, the contents of the cassette file is encrypted.