Bugzilla – Bug 153725
API url-escapes path components as query components
Last modified: 2006-10-26 13:58:35 UTC
http://api.opensuse.org/result/robert/factory/ACE/x86_64/log claims: ----------------------------------------------------------------- ----- building ACE.spec (user abuild) ----------------------------------------------------------------- ----------------------------------------------------------------- error: File /usr/src/packages/SOURCES/ACE-5.4.1+TAO-1.4.1+CIAO-0.4.1.tar.bz2: No such file or directory But when you look at http://build.opensuse.org/package/show?project=robert&name=ACE you can see that it is there. Escaping bug for '+'?
Yes, but in the frontend. The backend knows about: <directory srcmd5="46f39383eb67358b62a47a22b9aaf95e" rev="6" name="ACE"> <entry name="ACE.spec" md5="3f0866361d476fa628551ebf2acc82d9" /> <entry name="ACE-5.3-reactors.diff" md5="21910687dcbb5ee770b5428e1496c619" /> <entry name="ACE-5.4.1" md5="ea6d78fa667772bbab91f33a85d0e866" /> </directory> So the api or the web UI has provided the backend with a wrong file name.
Seems I was right with suspecting a escaping bug. Note that '+' is the escape sequence for a space. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Note that if you are not careful about handling this this might be usable for code injection attacks! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
This is fixed meanwile. Please check again, thanks.
Hmm, does still not work. I changed the spec file to trigger a rebuild resulting in the very same error.
You probably need to upload the broken file again.
No, even then the same error occurs.
I uploaded earlier today a source tarball named "pvm3.4.5+4.tar.gz" and the web frontend thinks that it is "pvm3.4.5". The build process fails because it could not find the file. This is for the OSCAR project, you can check the logs there. Thanks.
Still fails for me, too. I've been trying to upload Atlas-C++-0.6.0.tar.bz2, and all that ever gets uploaded is Atlas-C. This happens when using the command line tool, too.
*** Bug 181593 has been marked as a duplicate of this bug. ***
I added a workaround to the osc client.
I added the workaround to the webclient. The real problem is a bug in the rails framework which escapes parts of the URL path as if they were in the query string.
we patched rails to _not_ treat path elements as query parameters, so the workarounds aren't neccesary anymore.