Comments on: One Infinite Loop

By: youngnh

youngnh — Mon, 03 Aug 2009 21:55:43 +0000

So, the NSC_xxx.ofugmjy.dpn cookie gets set as the last header of the first 302 response.

I really think that Drakma did something clever and functional, like reuse the output from a previous request, or improperly binding a function in a closure, instead of something boring and stateful and imperative like using a loop.

My point was supposed to be that I worked myself into a tizzy over the Netflix server’s behavior before I realized that my tooling was probably to blame.

I’ll dip into the source code later this month and hopefully post back here with an update (and a fix?).

By: benjaminplee

benjaminplee — Mon, 03 Aug 2009 19:25:05 +0000

This is probably just a messed up copy/paste job but I also noticed that your second GET contains a cookie: NSC_xxx.ofugmjy.dpn which isn’t set on the first response nor is it sent with the initial request.

One more thing to look into. Good luck.

By: benjaminplee

benjaminplee — Mon, 03 Aug 2009 13:57:33 +0000

I wonder if you wrote a really simple HTTP server and mimicked NetFlix’s behavior if you could verify it isn’t because of some strange header setup with the client. You might be able to verify that Drakma doesn’t resend cookies during the same session as a rule.

You also might try using something like WebScarab to “pause” the responses as they come back to the browser and/or your Drakma client and try removing various headers. It might have something to do with how your Drakma client handles (or doesn’t handle) Keep-Alive connections or Cache-Control: private. Also, if you injected those cookies manually you could at least verify that Drama handles the response correctly.

Just some thoughts. Good post.