diff options
author | Nat Goodspeed <nat@lindenlab.com> | 2012-08-31 09:55:52 -0400 |
---|---|---|
committer | Nat Goodspeed <nat@lindenlab.com> | 2012-08-31 09:55:52 -0400 |
commit | 7db0cb7583b829be3b4884b69a31af1bbdfaadfb (patch) | |
tree | 23ae70c09c4e00ffb629990b508d8d810f28a46c /indra/llmessage/llpacketack.h | |
parent | b974422a07a4a7c689fb4096c0e70fbfb4342785 (diff) |
Fix longstanding LLURI::buildHTTP() bug when passing string path.
The LLURI::buildHTTP() overloads that take an LLSD 'path' accept 'undefined',
LLSD::String and (LLSD::Array of LLSD::String). A sequence of path components
passed in an Array is constructed into a slash-separated path. There are unit
tests in lluri_test.cpp to exercise that case.
To my amazement, there were NO unit tests covering the case of an LLSD::String
path. The code for that case escaped and appended the entire passed string.
While that might be fine for a 'path' consisting of a single undecorated path
component, the available documentation does not forbid one from passing a path
containing slashes as well. But this had the dubious effect of replacing every
slash with %2F.
In particular, decomposing a URL string with one LLURI instance and
constructing another like it using LLURI::buildHTTP() was not symmetrical.
Having consulted with Richard, I made the string-path logic a bit more nuanced:
- The passed path string is split on slashes. Every path component is
individually escaped, then recombined with slashes into the final path.
- Duplicate slashes are eliminated.
- The presence or absence of a trailing slash in the original path string is
carefully respected.
Now that we've nailed down how it ought to behave -- added unit tests to
ensure that it DOES behave that way!!
Diffstat (limited to 'indra/llmessage/llpacketack.h')
0 files changed, 0 insertions, 0 deletions