# Lifetime of sessions in \`net/http-easy\`

**URL:** <https://racket.discourse.group/t/lifetime-of-sessions-in-net-http-easy/3483>\
**Category:** Questions & Answers\
**Created:** [January 12, 2025, 11:24am UTC](https://racket.discourse.group/t/lifetime-of-sessions-in-net-http-easy/3483 "2025-01-12T11:24:52Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![bakgatviooldoos](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/bakgatviooldoos/32/1381_2.png) [@bakgatviooldoos](https://racket.discourse.group/u/bakgatviooldoos)\
**Post date:** [January 12, 2025, 11:24am UTC](https://racket.discourse.group/t/lifetime-of-sessions-in-net-http-easy/3483/1 "2025-01-12T11:24:52Z")

</div>

Hi, Racket Discourse.

I encountered an API (specifically [ThreatFox](https://threatfox.abuse.ch/api/)), which requires an SSL context for the session when making requests; I am using `net/http-easy`.

Easy enough, after I figured that part out, but now I am wondering how long-lived such a session value should be: Do you make a new session each time you are making a spate of requests, or is it fine to define one session and use this throughout the code's lifetime?

Looking at @bogdan's [source code](https://github.com/Bogdanp/racket-http-easy/blob/7d76be652042c2c4fd00f4ea4335d7d4fa25a9b9/http-easy-lib/http-easy.rkt#L46), it seems like the default session is such a long-lived value, but I would still like to confirm whether I am taking the correct approach, considering this is mostly fire-and-forget at this point.

An example of my current approach (using the latter method):

```scheme
(define ssl-session (make-session #:ssl-context (ssl-make-client-context)))

 ...

(define (search-ioc-info ioc)
  (define api-token (config:get-section 'api 'threatfox 'api-token))
  (define endpoint (threatfox:post-any))
  (define request (request/threatfox
                     api-token (hasheq 'query "search_ioc"
                                       'search_term ioc)))
  (parameterize ([current-session ssl-session])
    (response-json (request endpoint))))

```

---

<div class="post-metadata">

**Author:** ![bogdan](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/bogdan/32/8_2.png) [@bogdan](https://racket.discourse.group/u/bogdan)\
**Post date:** [January 12, 2025, 2:04pm UTC](https://racket.discourse.group/t/lifetime-of-sessions-in-net-http-easy/3483/2 "2025-01-12T14:04:28Z")

</div>

Sessions are intended to be long-lived. The main benefits of long lived sessions are connection pooling and a shared cookie jar (if provided when the session is created). They can also be short lived; it really depends on your use case. In this case, it seems like it would be fine to use the same session for the lifetime of your program. That said, the default session already comes with a secure SSL client context. Calling ssl-make-client-context with no arguments like in your example returns an insecure context (i.e. one that doesn’t validate certs), so that might not be what you want.

---

<div class="post-metadata">

**Author:** ![bakgatviooldoos](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/bakgatviooldoos/32/1381_2.png) [@bakgatviooldoos](https://racket.discourse.group/u/bakgatviooldoos)\
**Post date:** [January 12, 2025, 2:42pm UTC](https://racket.discourse.group/t/lifetime-of-sessions-in-net-http-easy/3483/3 "2025-01-12T14:42:08Z")

</div>

That makes sense, thank you @bogdan.

> [@bogdan](#):
>
> Calling ssl-make-client-context with no arguments ...

I have never had the occasion to make use of one until now, thank you for pointing that out!

Interestingly, using `'secure` causes a similar failure to the initial head-scratcher, but the `'tls13` and `'tls12` seem to work fine.

Neither the docs for the API nor the response headers mention it specifically, so I guess I'd have to run an `nmap` or similar to confirm the ciphers being used.

---

<div class="post-metadata">

**Author:** ![bakgatviooldoos](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/bakgatviooldoos/32/1381_2.png) [@bakgatviooldoos](https://racket.discourse.group/u/bakgatviooldoos)\
**Post date:** [January 12, 2025, 3:02pm UTC](https://racket.discourse.group/t/lifetime-of-sessions-in-net-http-easy/3483/4 "2025-01-12T15:02:11Z")

</div>

> [@bakgatviooldoos](#):
>
> Interestingly, using `'secure` causes a similar failure

Which is exactly what you said, lol 🙄

---

<div class="post-metadata">

**Author:** ![bogdan](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/bogdan/32/8_2.png) [@bogdan](https://racket.discourse.group/u/bogdan)\
**Post date:** [January 12, 2025, 4:09pm UTC](https://racket.discourse.group/t/lifetime-of-sessions-in-net-http-easy/3483/5 "2025-01-12T16:09:36Z")

</div>

> [@bakgatviooldoos](#):
>
> Interestingly, using `'secure` causes a similar failure to the initial head-scratcher, but the `'tls13` and `'tls12` seem to work fine.

You might give `'auto` a try in that case. The `'secure` protocol avoids weak ciphers, but it sounds like the remote is using one of those.

---

<div class="post-metadata">

**Author:** ![bogdan](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/bogdan/32/8_2.png) [@bogdan](https://racket.discourse.group/u/bogdan)\
**Post date:** [January 12, 2025, 4:31pm UTC](https://racket.discourse.group/t/lifetime-of-sessions-in-net-http-easy/3483/6 "2025-01-12T16:31:15Z")

</div>

_Looks like I can't edit this post, so:_

Actually, it looks like `'auto` does not verify certificates (and, probably, neither do the other protocol symbols). So, you would have to do something like the following to construct a secure context that allows weak ciphers:

```racket
(define ctx (ssl-make-client-context 'auto))
(ssl-load-default-verify-sources! ctx)
(ssl-set-verify! ctx #t)
(ssl-set-verify-hostname! ctx #t)
(ssl-seal-context! ctx) ;; optional
(define session (make-session #:ssl-context ctx))

```

---

<div class="post-metadata">

**Author:** ![bakgatviooldoos](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/bakgatviooldoos/32/1381_2.png) [@bakgatviooldoos](https://racket.discourse.group/u/bakgatviooldoos)\
**Post date:** [January 12, 2025, 4:40pm UTC](https://racket.discourse.group/t/lifetime-of-sessions-in-net-http-easy/3483/7 "2025-01-12T16:40:13Z")

</div>

Very interesting. Seems like the example from the `openssl` docs showing the equivalent construction for `ssl-secure-client-context`, if I am parsing this correctly, except for the `ssl-set-ciphers!` being omitted?

But unfortunately, no dice. If use the `session` from the above, I am left with:

```scheme
[error]
... ssl-connect: connect failed (error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed)

```

---

<div class="post-metadata">

**Author:** ![bogdan](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/bogdan/32/8_2.png) [@bogdan](https://racket.discourse.group/u/bogdan)\
**Post date:** [January 12, 2025, 4:47pm UTC](https://racket.discourse.group/t/lifetime-of-sessions-in-net-http-easy/3483/8 "2025-01-12T16:47:04Z")

</div>

> [@bakgatviooldoos](#):
>
> Very interesting. Seems like the example from the `openssl` docs showing the equivalent construction for `ssl-secure-client-context`, if I am parsing this correctly, except for the `ssl-set-ciphers!` being omitted?

Yep.

> [@bakgatviooldoos](#):
>
> But unfortunately, no dice. If use the `session` from the above, I am left with:

Sounds like you're missing a root certificate in that case in your local store in that case. I just tried making a(n invalid) request to that API with a secure context and everything works fine.

---

<div class="post-metadata">

**Author:** ![bakgatviooldoos](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/bakgatviooldoos/32/1381_2.png) [@bakgatviooldoos](https://racket.discourse.group/u/bakgatviooldoos)\
**Post date:** [January 12, 2025, 4:49pm UTC](https://racket.discourse.group/t/lifetime-of-sessions-in-net-http-easy/3483/9 "2025-01-12T16:49:37Z")

</div>

I'll have to check that out, then. Could be any one of the many network-related "security" softwares running on this poor machine.

Thank you so much for taking the time to troubleshoot that, it is greatly appreciated.
