Jump to content

Talk:URL encoding: Difference between revisions

This task is not restricted to HTTP urls
(more needed)
(This task is not restricted to HTTP urls)
Line 5:
::: Superseding RFCs may only supersede some of the functionality (such as for a protocol like gopher)
::: Superseded RFCs should be ignored
::: As this task seems to be about HTTP URLs we should ignore some of the RFCs for other protocols like mail, tn3270, etc. There are also RFCs that extend functionality such as for extensions of protocols such as WebDav which would seem not to be part of the core task. Also, some of these RFC's have been marked as 'historic' a polite way of sayng obsolete.
:::: This task is not restricted to HTTP urls, and can be applied to any string that can be encoded into this format.
:: I believe the example of an encoded url is in error (or not described properly). Specifically,
::: The string "http://foo bar/" would be encoded as "http%3A%2F%2Ffoo%20bar%2F".
::: Would only be encoded if this URL were being passed as data within another URL. See the RFC sections on Reserved Characters and When to Encode or Decode.
:::: The task is to demonstrate the encoding mechanism, rather than when to use the application of this, so we can assume that this will be used in applications where the URL string requires encoding. --[[User:Markhobley|Markhobley]] 13:01, 17 June 2011 (UTC)
:: There probably should be soome required input(s) and output(s). I noticed the perl example is very cryptic using a library and provides no output. The output it would produce doesn't match the 'example' string as it only encodes data in the path portion of the URL and not the entire URL.
: --[[User:Dgamey|Dgamey]] 09:54, 17 June 2011 (UTC)
Cookies help us deliver our services. By using our services, you agree to our use of cookies.