608 check not accepting endpoints#623
Conversation
WalkthroughThe changes in this pull request involve modifications to the Changes
Assessment against linked issues
Suggested labels
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Coverage Report
File Coverage
|
||||||||||||||||||||||||||||||||||||||
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
src/controllers/submitUrlController.js (2)
68-74: Consider documenting the null return value.The early return with null is a good pattern, but it would be helpful to document this behaviour in the method's JSDoc. This helps consumers of the API understand that null indicates a skipped validation rather than a validation failure.
/** * * @param {string?} url + * @returns {Promise<string | null | undefined>} Returns validation error type, null if validation was skipped, or undefined if validation passed */ static async localUrlValidation (url) {
68-82: Consider enhancing the URL validation strategy.The current changes solve the immediate issue, but consider these architectural improvements for future iterations:
- Implement a configurable list of endpoints or patterns where HEAD requests should be skipped
- Consider implementing a fallback to GET request with range headers for endpoints that don't support HEAD
- Add metrics to track how often HEAD requests fail to help inform future optimisations
This would make the solution more maintainable and adaptable to similar cases in the future.
test/unit/submitUrlController.test.js (1)
133-144: Consider adding test cases for WFS endpoints.While the current test coverage is good, consider adding specific test cases for WFS endpoints mentioned in issue #608:
https://maps.buckinghamshire.gov.uk/server/services/Planning/TPOs/MapServer/WFSServer?SERVICE=WFS&REQUEST=GetCapabilitieshttps://kingston.statmap.co.uk/map/wfs.svc/WFS_RBK_article4?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=statmap:RBK_article4&SRSNAME=EPSG:27700&outputFormat=application/jsonThis would ensure the fix specifically addresses the reported use cases.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
src/controllers/submitUrlController.js(2 hunks)test/unit/submitUrlController.test.js(1 hunks)
🔇 Additional comments (4)
src/controllers/submitUrlController.js (2)
11-12: LGTM! Well-defined constant for HTTP status code.
The constant follows proper naming conventions and uses the correct value for the HTTP 405 Method Not Allowed status code.
75-82: Remove redundant inline comment and verify impact.
Two suggestions:
- The inline comment on line 76 is redundant as the log message already explains the behaviour clearly.
- We should verify that this change doesn't affect other valid endpoints that might return 405 for different reasons.
if (headResponse?.status === HTTP_STATUS_METHOD_NOT_ALLOWED) {
- // HEAD request not allowed, return null or a specific error message
logger.warn('submitUrlController/localUrlValidation: failed to get the submitted urls head as it was not allowed (405) skipping post validators', {test/unit/submitUrlController.test.js (2)
134-138: Well-structured test for HEAD request failure scenario.
The test case effectively validates the new behaviour where HEAD request failures should return null instead of rejecting the URL. This aligns perfectly with the PR objectives.
140-144: Excellent coverage of the 405 status code scenario.
The test case properly validates the handling of endpoints that don't support HEAD requests, which directly addresses the core issue described in #608.
…k-not-accepting-endpoints
GeorgeGoodall-GovUk
temporarily deployed
to
development
GitHub Actions
Inactive
4 participants
What type of PR is this? (check all applicable)
Description
after a url is submitted in check, During local validation when we get the HEAD object of the url. if the server that hosts the submitted URL doesn't allow head requests, or if the head request fails. don't attempt to perform validations on the head object
Related Tickets & Documents
QA Instructions, Screenshots, Recordings
You can test with this known endpoint, where a head request returns status 405 (method not allowed). but the file itself is valid and should return some check results
Added/updated tests?
Summary by CodeRabbit
New Features
Bug Fixes
Tests