It seems like this is the regex that we're using to parse the auth flag value.
(for future reference: at the time of writing this the pattern is:^(.+):([^\s].+))
And I think that we can definitely improve it (beyond just supporting my weird use case 😅 ).
It isnt as pretty but I think that something like the would be better
Even if the above isnt acceptable replacing the greedy operators with lazy ones should be considered since the current pattern could group things incorrectly.
Also FWIW:
It is a pretty weird to have a blank username, but I believe its valid for it to be blank I could very well be wrong on that though so grain of salt and stuff
control characters are not valid for username or password
the username cant contain a colon :
but my experience with specifications has been that there is always some addendum or reference to a separate document that I've overlooked that changes the rules. 😂
Fair warning: I am not super familiar with go, and most of the below is the result of a quick cmd+f through the entire project
The parser for the authentication flag value fails if the username in the string is empty. e.g.
hey -m GET -a ":cr@zE|>455w0rd" https://url.com
I noticed this while trying to use hey on an older API I have to maintain.
grepping for "auth" in the project lead me to this line in hey.go
It seems like this is the regex that we're using to parse the auth flag value. (for future reference: at the time of writing this the pattern is:
^(.+):([^\s].+)
)And I think that we can definitely improve it (beyond just supporting my weird use case 😅 ).
It isnt as pretty but I think that something like the would be better
^(\b[^:]*?)?:(\b.*?)?$
Regex101 example with more notesEven if the above isnt acceptable replacing the greedy operators with lazy ones should be considered since the current pattern could group things incorrectly.
Also FWIW:
It is a pretty weird to have a blank username, but I believe its valid for it to be blank I could very well be wrong on that though so grain of salt and stuff
The basic authentication specification only lists the requirements as:
:
but my experience with specifications has been that there is always some addendum or reference to a separate document that I've overlooked that changes the rules. 😂