CORS preflight response headers stripped in browser proxying mode

[Jeremy Lew]

Hello,

I'm trying to capture some responses from a webview embedded in my mobile app.  WireMock is in browser-proxy mode, which is working well in general to capture both native networking and webview requests from the app. However when being proxied, the webview is rejecting certain XHR (fetch) requests.  What seems to be happening is that the preflight response headers, when proxied by WireMock,  do not contain the "Access-Control-XXX" headers.  I suspect that one of two things is happening:
a)  For some reason, the headers were sent by the server, but are being stripped by WireMock.
b) The headers are not being sent by the server when WireMock is proxying the requests.

I'm not sure why either one of these would be the case, or how to tell what the problem really is.  Any help appreciated!

Thanks,

Jeremy

[Tom Akehurst]

Are you on the latest version?

I fixed a bug relating to this for 2.28.0 so if you're on an earlier version you might find an update fixes your issue.

[Jeremy Lew]

Hi Tom,

I am building it myself from the master branch, which I pulled this morning, so I assume that would have the latest.

[Tom Akehurst]

In that case please can you share details of what you're trying so I can attempt to replicate the issue?

Or if you can, provide a failing test case?

[Jeremy Lew]

I'm not at all sure how to make a test case in the project, but here's an easy repro:

1. Run wiremock on localhost in browser-proxy mode

2. Execute curl  to simulate a browser preflight OPTIONS request, proxying through wiremock, like so:

curl -H "Origin: https://sportsbook.draftings.com" \

  -H "Access-Control-Request-Method: GET" \

  -H "Access-Control-Request-Headers: X-Requested-With" \

  -X OPTIONS --verbose \

  --proxy localhost:1080 \

  --http1.1 \

  "https://api.draftkings.com/sites/US-SB/addresses/v1/countries/US/regions?format=json" ;

3. Notice the response headers look like this:

< Content-Type: text/plain

< X-Frame-Options: SAMEORIGIN

< Date: Fri, 25 Jun 2021 20:39:12 GMT

< Content-Length: 7

<

4. Compare that to the same curl request with the --proxy argument removed.  You'll see that the response has a bunch more headers, including what you need for preflight authorization like:

< Access-Control-Allow-Credentials: true

< Access-Control-Allow-Headers: X-CSRF,Accept,Accept-Language,Content-Language,Content-Type,Accept-Encoding,Cookie

< Access-Control-Allow-Methods: GET,POST,PUT,DELETE,PATCH

< Access-Control-Allow-Origin: *

< Access-Control-Expose-Headers: Date,ETag

< Access-Control-Max-Age: 300

< Content-Type: text/plain

< X-Frame-Options: SAMEORIGIN

< Date: Fri, 25 Jun 2021 20:05:03 GMT

< Content-Length: 7

< Connection: keep-alive

I tried to set some breakpoints in WireMock to see what is going on haven't seen anything illuminating so far.