-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 6/30/17 5:11 PM, Mark Thomas wrote: > On 30/06/17 22:06, Christopher Schultz wrote: >> Mark, >> >> (This time, to the list and not just you) >> >> This seems like the wrong approach. >> >> I think you want to leave the URLEncoding alone and instead >> XML-escape anything you intend to put into an XML document >> separately. >> >> You want the XML to end up looking like this: >> >> <element>url.which.contains.a.&.symbol</element> >> >> and not this: >> >> <element>url.which.contains.a.%26.symbol</element> >> >> Or am I misunderstanding what's going on, here? > > Arguably, & is the more correct but either approach is legal as > far as the specifications are concerned. I'm surprised to hear that they are equivalent. If I were writing a WebDAV client (and it's probably good that I wouldn't take this naïve approach, I guess), I would expect that the URLs coming back should be XML-decoded (of course, the XML library ought to do this for me). Let's say I have a file on the disk named "H&M.txt". In the XML, I'll get back "H%26M.txt" as the filename. When I convert that to a URL, I'll urlencode it and get "H%2526M.txt". If I try to request that file, I'll fail, because I need to request "H%26M.txt" or "H&M.txt" but instead I've double-encoded the filename. Is this something unique to the WebDAV spec (which I haven't read, obviously)? > Since we need to URL encode anyway, fixing this via tweaking the > URL encoding looked to be simpler. It was also consistent with how > it was working before the regression was introduced. Interesting. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZVsAsAAoJEBzwKT+lPKRYZwgP/iAtunbqVhq5g8l7Bhr/wXWs mKFrg0PvjynUpCbiUMt8dRgm5lQhMjX2cPofqL45gVvGU6jfZKPFWaRIxdp2r65S o7v1okYlbLNfg9sCxBLcm5Ck1sw4+ROTsho/Pgj8BYnTe0uaOynOoQCvNKI2Jeyo If7OKpDFC29RqUFsLElRN3x5TWHN0nkFUnaBKgaDcWwak5ncPwLW7RGfBu7DgPDn s1V5DfxUCh0fFQuDsdEOSPXZYHgWyMKo7NYGxWUb8hebzOHIjcTZqA/LMmBC3e3A n/2x/fkh5ujipj4oEZYQxk4vuuGkJaCqfxDbicBXgXWMccxVPFQK8EW6Uk7oIUSz /JyW3kwWZVclP4VENZTkZtv+udw45ENsLuJxY8SaiEeqsi6yYVUVT0mtZgoZb6YK 7DePYd4xxSRnhV9GsejPmerXdqowYa2hV3CPIPAh+gfangXUJOlg3RcmbW30UWxQ 7dclxPb+z7x9q/XYl50dXcNvSltyeGcOa/erR4r4dJxY/IEs8sty8w/Ud0PhBMJl YIHRCKgresuTol23oRA4vbCAHW8cbJFgJ7LQuTy98N4d0VXyFqxg/nPSBNjrk/LA ro10STvsVQnx103mAndSiTPZEaalGRqzgr1dsB6HvpBdCPFd1nPDZh/6WDz3m8xO alpe/9EuxU18mZ0x9ZOD =YVkK -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
