I get 404 for some requests, while it works in browser

[vox-frl]

Hello,
I am working on a scenario to test one of our products. It basically is a React webapp, with a Java Spring backend.
The first page is a login page, containing a BotDetect Captcha. Url for the page is http : // 127.0.0.1:8080 / myContext/pages/identification.
The captcha is loaded through a fragment of html, with a specific url : http : // 127.0.0.1:8080 / myContext/simple-captcha-endpoint?get=html&c=identElecteurCaptchaFr
It contains references to sound and reload icons for the captcha :

<img class="BDC_ReloadIcon" id="identElecteurCaptchaFr_ReloadIcon" src="../includes/election/images/botdetect_refresh_32.png" alt="Recharger le code du Captcha" />
<img class="BDC_SoundIcon" id="identElecteurCaptchaFr_SoundIcon" src="../includes/admin/images/botdetect_speaker_32.png" alt="Écouter le code du Captcha" />

In browser, this fragment is integrated in the page, and both icons urls are relative to current page url, i.e.
http : // 127.0.0.1:8080 / myContext/includes/election/images/botdetect_refresh_32.png and http :// 127.0.0.1:8080 / myContext/includes/admin/images/botdetect_speaker_32.png
Images load fine, and it is the expected behaviour.

However, when I make the request to the html fragment from Gatling :

http("Captcha fragment Get")
.get("/simple-captcha-endpoint?get=html&c=identElecteurCaptchaFr")
.header("X-XSRF-TOKEN", "${xsrfToken}")
.check(substring("BDC_CaptchaImageDiv"))
.check(Check.captchaId)
.check(status.is(Constants.successStatus))

I receive 404 errors for both images, because I suppose their URL is relative to the html fragment url, and not the parent page url. They are missing myContext because of the “…” in their src in the fragment.
http : //127.0.0.1:8080 / includes/election/images/botdetect_refresh_32.png
http : //127.0.0.1:8080 / includes/admin/images/botdetect_speaker_32.png

The easiest solution would be to ignore 404s for this call, but I don’t like it. You guys have another idea about how to deal with this case?
Thanks!

[sbrevet]

Hi @vox-frl,

I don’t see /myContext in your get url. Is it in the baseUrl?
I never experienced that myself, but I do think that you need to remove it from your baseUrl and set it in your get url to be able to go to it. Please try that.

Cheers!

[vox-frl]

Yes, the context is set in the baseUrl.
I tried to remove myContext from baseUrl and set it in all my further requests, but I have same behaviour
I guess Gatling calculates the URL of the two images from the fragment URL, and not from the original page URL.
This is a fiddler screenshot, where problem can be seen :

[slandelle]

Is your fragment fetched as a resource, or as top level request?

[vox-frl]

Hello,
I’m not sure to be clear about the difference, but I load the fragment with a specific request, it’s not inferred. In a real browser, it’s loaded through the React JS app.
In my first message earlier today, I added the code I have in the scenario to load it.

[slandelle]

Gatling resources: Gatling - HTTP Request

In my first message earlier today, I added the code I have in the scenario to load it.

Doesn’t show if the request is in an exec or in a resources block, hence my asking.

Not sure if it would work for you, but that would be the only way for Gatling to possibly understand that the inferred resources relative urls should be resolved against the main request url (= “the page”) and not the url returning the HTML content.

If it doesn’t work, you’ll have to stop relying on automatic resources inference and add these resources explicitly.

Then, I’m always very skeptical about including static resources in a load test. These should be served by a cache and your performance under load issues are unlikely to be there.