Do the RFCs and whatnot list those characters as valid in a URI query?
The question comes up because - despite Rails's joyful abuse of those characters to delimit records - some of our params are coming in not like this...
"record[first_name]" => "yo"
...but like this:
"record first_NAME " => "yo"
The raw query has %20 marks for the spaces.
So what's doing that? And why is the NAME in caps?? So far, the only thing the User Agents have in common is "Windows 5.1" and some version of "Firefox".
Fernando Perez wrote:
The question comes up because - despite Rails's joyful abuse of those characters to delimit records
???
An "URI" is an URL. Rails packs records into them like this:
.../controller/action?record[first_name]=norbert&record[last_name]=theNark
The params method unravels them into params[:record] as a convenience. But does the industry in general support this use? or is it an artifact of "browser forgiveness"?
And has anyone ever seen user-agents convert them to "record first_NAME " for no reason?
The question comes up because - despite Rails's joyful abuse of those characters to delimit records
???
An "URI" is an URL. Rails packs records into them like this:
.../controller/action?record[first_name]=norbert&record[last_name]=theNark
The params method unravels them into params[:record] as a convenience. But does the industry in general support this use? or is it an artifact of "browser forgiveness"?
Don't know for sure, but I know that in the late 90's PHP used for this exact same thing. Still does I would assume. So if it's browser forgiveness it's something that has been going on since at least 1996.
And has anyone ever seen user-agents convert them to "record first_NAME " for no reason?
No.
Philip Hallstrom wrote:
Don't know for sure, but I know that in the late 90's PHP used for this exact same thing. Still does I would assume. So if it's browser forgiveness it's something that has been going on since at least 1996.
As a shotgun attack, we upgraded our HTML headers from variously nothing, or us-ascii, to:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
I copied it out of the top of a WikiPedia page, so it doubtless has had the crap reviewed out of it...
I copied it out of the top of a WikiPedia page, so it doubtless has had the crap reviewed out of it...
Also, we are naturally flattening our forms to not use in this context. We will also take out all the _, but that might just be collateral damage.
Hi,
Just wondering why you are taking out the "_"?
Brandon
Brandon Olivares wrote:
Just wondering why you are taking out the "_"?
Some commie or terr'ist somewhere has a browser that replaced peace_freedom with peaceUS95freedom. That _might_ have been caused by the accidental us-ascii encoding on the page - 95 is the ASCII code point for _ - but it still spooked our Onsite Customer, so away with it.
The RFC 3986, warns about these "[","]" characters, but leaves it up to the implementor. Firefox, IE and Safari browsers support these characters. http://tools.ietf.org/html/rfc3986
"Special care should be taken when the URI path interpretation process involves the use of a back-end file system or related system functions. File systems typically assign an operational meaning to special characters, such as the "/", "\", ":", "[", and "]" characters, and to special device names like ".", "..", "...", "aux", "lpt", etc. In some cases, merely testing for the existence of such a name will cause the operating system to pause or invoke unrelated system calls, leading to significant security concerns regarding denial of service and unintended data transfer. "
The now, obsolete http://www.ietf.org/rfc/rfc2396.txt, had them listed as unwise characters " Other characters are excluded because gateways and other transport agents are known to sometimes modify such characters, or they are used as delimiters.
unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"
Data corresponding to excluded characters must be escaped in order to be properly represented within a URI. "
Phlip wrote: [...]
An "URI" is an URL. Rails packs records into them like this:
.../controller/action?record[first_name]=norbert&record[last_name]=theNark
I don't use GET with very often in Rails, but when I have done so, I have noticed that the are always URL-encoded as %xx (don't remember the number offhand). Either are illegal in URLs or the browser is playing it safe.
Could you use POST or custom routing in this case?
The params method unravels them into params[:record] as a convenience. But does the industry in general support this use? or is it an artifact of "browser forgiveness"?
PHP does it, as others have pointed out.
And has anyone ever seen user-agents convert them to "record first_NAME " for no reason?
Surely not! That's bizarre!
A thought: I reported a weird bug with nested params back in January or so (check this list or Lighthouse). Fred patched it, but I don't know when the patch made it into core, if it ever did. Perhaps this is related?
Best,