Proudly Canadian 
Anonymous case study · Applications and security
ApplicationMoodle
PayloadJSON requests
Failure pointWeb application firewall
ValidationSuccessful HTTP 200
Restoring Moodle JSON requests blocked before PHP
A learning platform could serve normal pages, but specific JSON requests failed before the application had a chance to process them. Gotekky reproduced the behaviour, isolated the web application firewall rule and restored the required requests without removing wider protection.
Client profile
An organization operating a Moodle learning platform with application requests that depended on JSON payloads.
The challenge
The failure occurred before Moodle could log or handle it.
The platform’s ordinary pages did not reveal the full issue. Requests carrying a particular JSON pattern were rejected at the web server security layer, so application logs alone could not explain the failure.
Because the rejection happened before PHP, changing Moodle code or application settings would not have corrected the underlying problem.
Architecture and technical path
Where the request was interrupted
Testing across each layer showed that the application was not generating the rejection.
Gotekky response
The investigation followed the request through each technical layer.
Reproduce the exact payload
The failing request was recreated with the same method, content type and JSON characteristics instead of relying on a generic page test.
Identify the rejection layer
Response behaviour and security logs confirmed that the web application firewall generated the failure before PHP executed.
Scope the exception
The exception was limited to the necessary application path and request behaviour rather than applied to the whole domain.
Retest with security active
The same JSON request was submitted again while the wider security policy remained enabled.
Confirm the application response
A successful HTTP 200 response verified that the request reached Moodle and completed normally.
Validation
A successful response confirmed the complete request path.
The decisive test was not whether a static page loaded. It was whether the original JSON request passed through the security layer, reached PHP and produced the expected Moodle response.
The final HTTP 200 validation demonstrated that the narrow correction solved the actual application problem.
What this demonstrates
Application troubleshooting must include every layer that handles a request. When a request fails before PHP, the correct evidence comes from controlled reproduction, web server behaviour and security logs, not application changes made by guesswork.
Does an application request fail before it reaches your code?
Share the response code, request type and a reproducible example. Gotekky can trace the request across the web server, security and application layers.
The initial conversation is free. A paid investigation is proposed only when it is genuinely required.