3

The rfc 1738 is not precise about encoding of forward slashes in "search part":

If the character corresponding to an octet is reserved in a scheme, the octet must be encoded.

...

only alphanumerics, the special characters "$-_.+!*'(),", and reserved characters used for their reserved purposes may be used unencoded within a URL.

...

Within the 'path' and 'searchpart' components, "/", ";", "?" are reserved.

Do you know what is the "reserved purpose" of "/" in search part of the urls?

Is there any real reason to follow the spec and encode the forward slashes providing that my server handles unecoded slashes?

It drive me nuts when I need to constantly decode urls parameters that are just alphanumeric with slashes.

Here is an life example:

http://localhost/login?url=/a/path/to/protected/content

vs

http://localhost/login?url=%2Fa%2Fpath%2Fto%2Fprotected%2Fcontent"

Piotr Czapla
  • 25,734
  • 24
  • 99
  • 122

1 Answers1

2

Note that RFC 3986 updates RFC 1738 (though doesn't obsolete it, which I think indicates that it's intended to clarify rather than contradict).

RFC 3986 says, in section 3.4, that the syntax of the query part of the URI is:

query       = *( pchar / "/" / "?" )

The ABNF for URIs is conveniently collected in Appendix A, which indicates

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
pct-encoded   = "%" HEXDIG HEXDIG
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
              / "*" / "+" / "," / ";" / "="

That pretty unequivocally indicates that slashes are legitimate in the query part, and so don't need to be encoded. In particular, your example http://localhost/login?url=/a/path/to/protected/content is fine as it is, and so is http://localhost/login?abc123-.+~!$&'()*+,;=%00/?:@

Section 2.4 indicates that characters need to be encoded only when one wants to include reserved characters in a part of the URI (that doesn't apply here).

Norman Gray
  • 11,978
  • 2
  • 33
  • 56