[asterisk-bugs] [Asterisk 0018046]: [patch] func_curl CURLOPT likes a querycomponent (+-decoding) hashcompat mode
Asterisk Bug Tracker
noreply at bugs.digium.com
Sun Sep 26 22:43:50 CDT 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=18046
======================================================================
Reported By: wdoekes
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 18046
Category: Functions/func_curl
Reproducibility: always
Severity: feature
Priority: normal
Status: feedback
Asterisk Version: 1.6.2.13
JIRA:
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2010-09-24 04:16 CDT
Last Modified: 2010-09-26 22:43 CDT
======================================================================
Summary: [patch] func_curl CURLOPT likes a querycomponent
(+-decoding) hashcompat mode
Description:
Hi,
in https://issues.asterisk.org/view.php?id=18037 I've added a QSFIELD
which is pretty much obsoleted by the hashcompat mode of CURLOPT.
However, the ast_uri_decode leaves +'es verbatim in the decoded output,
where I expect them to be decoded to spaces.
The attached patch adds a hashcompat=querycomponent mode that decodes the
pluses properly. (For backwards compatibility the ast_value() works for all
other values.)
Regards,
Walter Doekes
OSSO B.V.
======================================================================
----------------------------------------------------------------------
(0127413) tilghman (administrator) - 2010-09-26 22:43
https://issues.asterisk.org/view.php?id=18046#c127413
----------------------------------------------------------------------
Yes, that is logical. But if you look at the same RFCs, you'll find that
while '+' is still a reserved character for the HTTP URI, encoding a space
SHOULD be done as '%20', NOT as '+'. In other words, you need to change
whatever the other side is using to be compliant, not to add a mode to
Asterisk that is equally non-compliant.
Please see RFC 1738, section 3.4.7 for an example of why a space is NEVER
encoded as a '+'. To do so is simply wrong.
Issue History
Date Modified Username Field Change
======================================================================
2010-09-26 22:43 tilghman Note Added: 0127413
======================================================================
More information about the asterisk-bugs
mailing list