summaryrefslogtreecommitdiff
path: root/indra/llcommon/tests/lluri_test.cpp
AgeCommit message (Collapse)Author
2015-11-10remove execute permission from many files that should not have itOz Linden
2013-03-29Update Mac and Windows breakpad builds to latestGraham Madarasz
2012-08-31Fix longstanding LLURI::buildHTTP() bug when passing string path.Nat Goodspeed
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!!
2010-08-13Change license from GPL to LGPL (version 2.1)Oz Linden
2009-10-16DEV-41080 more automated testing love - minor comment fixing.Adam Moss
2009-10-15DEV-41352 convert lluri tut test to a llcommon integration testAdam Moss