SPNEGO-based Kerberos authentication: Should I create a new security context using `gss_init_sec_context` for every request?

SPNEGO-based Kerberos authentication: Should I create a new security context using `gss_init_sec_context` for every request?

I'm implementing SPNEGO-based Kerberos authentication for a Linux client application for authenticating requests to a Windows IIS server.

I've read RFC4559, which describes how authentication should be performed:

https://datatracker.ietf.org/doc/html/rfc4559

My questions are as follows:

1. Should I create a new security context using gss_init_sec_context for every HTTP request, and is it expensive to do so? Curl creates a security context per request, but it only performs a single request: https://github.com/curl/curl/blob/c44671ed431aa3d40819e59f63c471be158480a7/lib/krb5.c#L348
2. How can I use this form of authentication with PUT/POST requests? I don't know in advance from the result of gss_init_sec_context whether the server will return HTTP 200 or HTTP 401 Negotiate (continuation). Hence, I don't know when to send the PUT/POST body?

When using the SPNEGO HTTP authentication facility with client-supplied data such as PUT and POST, the authentication should be complete between the client and server before sending the user data. The return status from the gss_init_security_context will indicate that the security context is complete. At this point, the data can be sent to the server.

3. It seems ineffective to perform negotiation (authentication) for every request. Why isn't the client authenticated once, with the resulting token being accepted for successive request, like it's the case with OAuth2.0?