Hi,
Where this limit came from?
It was added to find some problems with the SSL code. I'm not sure if it's still needed, you might want to change the 16000 to some higher value. (Some limit is still good to have to detect really broken streams instead of using up all memory.)
Increasing the limit doesn't help. That was the first thing I tried. It leads to long wait and result is just a couple of chunks. The rest is lost somewhere.
BTW, wget handles direct request to the same url (not through the link) just fine: wget --no-check-certificate "https://api.bad.obs/public/build/:project/distro/arch/_repository?bina ry=fo o&view=cpio" -O- -q |cpio -t foo.rpm 121 blocks
Correct me if I'm wrong, but it looks like a bug somewhere in obs code.
After some more digging I realized that current obs code just can't process HTTP chunks bigger than 16384 bytes. It expects the whole chunk to fit into the buffer(recvbuf) which is used to read data from a socket. However, there is no limit for HTTP chunk size in RFC 2616 and my case confirms that in reality chunks can be much bigger. Maximum I've seen is more than 200K. Here is my fix: https://github.com/openSUSE/open-build-service/pull/30 I tested it on obs 2.1.16 and it solves the problem explained in this thread. Sorry, for the ugly code. I'm not a Perl programmer by any means. Regards, Ed -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org