Actually - this makes me think 'Content Length' on a HTTP upload is not
a suitable measure of the file size - this is the length being sent to
the server, not necessarily the actual size of the resulting file.
On 04/11/15 14:06, Brian Stansberry wrote:
It shouldn't as part of the management API, no. Any total
information that gets exchanged is part of the underlying management
communication protocol used for propagating streams and isn't exposed
outside that layer. I'd like to see even that bit go away too, as it's
unnecessary and wastes resources on the client.
 In some cases the CLI actually sends the deployment bytes base 64
encoded as a param to the op, in which case the size info is available
to the operation step handler. I consider that CLI behavior to be a bug
On 11/4/15 7:52 AM, Darran Lofthouse wrote:
> Does the op in the CLI send any length information? That would help the
> two be consistent.
> On 04/11/15 12:29, Jason T. Greene wrote:
>> On Nov 4, 2015, at 4:36 AM, Heiko Braun <hbraun(a)redhat.com
>> <mailto:email@example.com>> wrote:
>>> GWT boils down to plain web technologies. And no, AFAIKT there is no
>>> way to check the size of an uploaded file across web browsers. Most
>>> browsers do however have an implicit limitation on the file size,
>>> which for majority is about 2 GB.
>> You can now that we have switched to XHR to do the upload. The File
>> object returned from a file list has a size property that you can use.
>> So you could in theory check that there is available space before
>> posting, however, since as Stuart mentions, browsers set a content
>> length, the server knows it anyway so it's less racy checking at the
>> server level, if one was to check.
>>>> On 04 Nov 2015, at 10:11, Darran Lofthouse
>>>> From within GWT is there any option to detect the file size before
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org <mailto:firstname.lastname@example.org>
> wildfly-dev mailing list