Support custom HTTP methods + leniently parse flattened cURLs - #99
Conversation
cURL import previously rejected any method outside a fixed allow-list and silently mis-parsed multi-line cURLs that were flattened onto a single line (leaving a stray `\` from the dropped line continuation). - validateCurlRequest now accepts any syntactically valid HTTP method token (RFC 7230), so custom methods like MKCOL/PROPPATCH import correctly. Only the -XPOST glued form re-extracts the method, so a bare `-X` no longer clobbers a method parsed from a separate token (which produced the blank "The method is not supported" error). - sanitizeArgs strips a backslash flanked by whitespace, so a flattened `... \ -X POST` continuation still parses the following flags. An escaped space inside a word (path\ with\ space) is left untouched. Co-Authored-By: Claude <noreply@anthropic.com>
VShingala
left a comment
VShingala
left a comment
There was a problem hiding this comment.
Core changes looks good, only issue I see is related to support of flattened multi-line cURL which we don't gurantee supporting.
| // (i.e. a standalone continuation artifact) so the following flag is parsed. | ||
| // An intentionally escaped space inside a word (e.g. `path\ with\ space`) has a | ||
| // non-whitespace char before the backslash and is left untouched. | ||
| string = string.replace(/(\s)\\(?=\s)/g, '$1 '); |
There was a problem hiding this comment.
This can be risky IMO, we're adding this logic assuming that we support flattened multi-line cURL. But these are inherently wrong cURLs itself.
Supporting this case result in existing valid usecase being broken.
@giridharvc7 Is it okay if we remove it? It shouldn't affect the core logic we added in this PR.
Only test case parse a flattened multi-line cURL with stray "\\ " line continuations should fail which anyway should since we can not gurantee importing incorrect cURL imports that don't itself work in bash.
| }); | ||
| }); | ||
|
|
||
| it('parse a flattened multi-line cURL with stray "\\ " line continuations', function (done) { |
There was a problem hiding this comment.
We can remove this based on above comment.
2 participants
What
Two related cURL-import robustness fixes:
Custom HTTP methods. Import previously rejected any method outside a hard-coded allow-list (
GET,POST, …,QUERY). It now accepts any syntactically valid HTTP method token (RFC 7230token), so custom methods likeMKCOL,PROPPATCH,BREWimport correctly. Methods that aren't valid tokens (e.g. containing a space) are still rejected.Lenient parsing of flattened multi-line cURLs. When a
\-continued multi-line cURL is pasted onto a single line, the newline is lost but the backslash remains (... \ -X POST \ --data-raw '{}'). The shell treats\as an escaped space and glues it to the next token, so the following flag was dropped and the request silently fell back toGETwith the body lost. We now strip a backslash that is flanked by whitespace (a standalone continuation artifact). An intentionally escaped space inside a word (path\ with\ space) is left untouched.Why
GET— reported againstQUERYbut it affected every method identically.-Xre-extraction clobbered a correctly-parsed method to empty, producing the confusingThe method is not supported.error (blank method name).Testing
MKCOL), glued form (-XPROPPATCH), flattened\continuation, and updated the invalid-method test to a genuinely invalid token (BAD METHOD).Generated with Claude Code