in reply to Re^2: How encode space into %20 in URI
in thread How encode space into %20 in URI

"I personally wouldn't call it an "issue" because AFAIK it's optional whether spaces should be escaped as %20 or +, ..."

If you look in the paragraph where I used the word "issue", you'll see:

"It would make sense that the escaping mechanism was consistent across modules in the same distribution"

I consider the inconsistency to be an issue. I made no reference to %20 or + being better, preferred, more correct, or anything else of that ilk.

"... and it's been that way for a long time."

Yes, I know. I was coding such escapes more than two decades ago.

"From URI's Changes file:"

I would question the relevance of including that entry from almost 22 years ago; it even references HTML4 which certainly isn't current. All that I'm getting from it is: "We changed %20 to + in some places, even though we believed that to be wrong, and left everything else in an inconsistent state".

— Ken

Replies are listed 'Best First'.
Re^4: How encode space into %20 in URI
by haukex (Archbishop) on Dec 22, 2022 at 11:42 UTC
    I consider the inconsistency to be an issue.

    I see your point, and it would be an option for URI to include a config option to encode spaces as %20 instead of + in the query. OTOH, I think the reason for the OP asking this question is strange, because it seems that either OP doesn't know that + is a valid encoding for space or there is some other misunderstanding of URIs, or perhaps they're building a workaround for a server that doesn't handle +, which would also be strange, and I might suggest (also) looking into the latter problem.

    I would question the relevance of including that entry from almost 22 years ago

    It was a reply to your "I don't know if the '%20' vs. '+' issue has always existed, or if it's something that was inadvertently introduced with some change." (Update: Emphasis mine.) A git blame shows the relevant lines of s/ /+/g; have been unchanged for 22 years.

    it even references HTML4 which certainly isn't current

    As I linked to in my other node, in this instance the HTML5 spec is backwards compatible with HTML4.