On Fri, May 23, 2014 at 06:28:58PM +0200, Andrew Phillips wrote: > >I've just seen JENKINS-23049 [1], and I recall some changes in jclouds > >to fix this. > > By the looks of it, this behaviour would be expected? Trying to > upload a blob with a payload but no content length seems to be > supposed to fail [1]. See JCLOUDS-508 [2] for a related comment, and > an answer from Gaul to a Stack Overflow question [3]. > > The only vaguely recent (over a year ago ;-)) change I can think of > relating to content length is [4], but that's at a really low level.
Agree with your assessment. JENKINS-23049 does not have enough context to determine whether this is a regression or not; I suspect that someone addressed a deprecation warning within Jenkins, changing a ByteArrayPayload to a ByteSourcePayload. The former gives an implicit content length while the latter does not, yielding the symptoms described. Unfortunately we cannot implicitly populate length efficiently for all ByteSource implementations. We could do something similar to the first half of ByteSource.size, calling countBySkipping. Or we could recommend use of new Payloads.newPayload wrappers which populate length for byte[] and File parameters. I am not yet convinced that we need a solution to this but encourage feedback on my ByteSource commits since some of this API redesign is not straightforward. -- Andrew Gaul http://gaul.org/
