Performing Preflight Requests Inside Middleware

[AndrewCEmil]

Hi! I'm trying to figure out a way to perform preflight requests within my middleware. Roughly speaking it would look something like this:

1. User makes a POST
2. Middleware gets called (before request is made)
3. Middleware makes a HEAD request
4. Based on the result of HEAD, the POST env is modified
5. env is forwarded to call

While I could simply do Faraday.new.head(url), I would like to make sure that the preflight request uses a connection that very closely mimics the original connect, including all options and middleware used (excluding body and method, of course).

Is there a way to construct such a connection? I wouldn't mind manually moving everything in the env over, but I don't see any information about the middleware in use on the original connection there. Perhaps its part of the app object?

Thanks for any help!

[iMacTia]

@AndrewCEmil interesting request, I never found myself wanting to do this, but it should definitely be possible.

I checked how preflight requests are performed (MDN docs) and I noticed the following:

• The method used should be OPTIONS, not HEAD;
• The request should contain no body
• The request should have only 3 headers

Based on the above, I don't think reusing the connection in your middleware is a good idea.
Connections normally contain middleware that add headers and modify the body, among other things.

So your original hunch of simply calling Faraday.head (this is a shorthand for Faraday.new.head) is in my opinion the way to go.
The only downside I see is that this will effectively open a new socket connection to the server, and reusing the existing one (especially if relying on a non-blocking or a persistent adapter) might be preferable.

So a possible better alternative would be for the middleware to make a copy of env, replace it with a new env for the preflight request and pass that down the chain. Then, upon receiving a positive response, the middleware will replace the old env and fire the request again.

Such a mechanism is hard to achieve with the standard on_request and on_complete callbacks, and will instead require a more advanced usage of the call method. A great example of how to do this is to check the retry middleware.

[AndrewCEmil]

So a possible better alternative would be for the middleware to make a copy of env, replace it with a new env for the preflight request and pass that down the chain. Then, upon receiving a positive response, the middleware will replace the old env and fire the request again.

This sounds great, I think that would definitely solve my problem.

I think the linked docs are specifically for CORS preflight requests - I might be misusing the term "preflight" here, I guess I meant something more like "a request made before the original request to gather required info". In this case, I need to do a header-based negotiation for special content-encoding. That being said, I think OPTIONS might be a better fit. In particular because HEAD is supposed to mimic GET response headers, but the original request here is for a POST.

Thanks so much for your help, really appreciated!