You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Matt Ryan <ma...@apache.org> on 2019/07/18 00:06:34 UTC
Backport OAK-7998 to 1.10.3
Hi,
I propose to backport the fix for OAK-7998 to 1.10.3.
The issue in OAK-7998 is that it is possible to obtain a direct download
URI for a binary that doesn't exist in blob storage. While not usually
possible, this situation can arise if the binary in question was added via
addRecord() and then a download URI is immediately requested, if the binary
is in cache and is not yet uploaded to cloud storage. In such a case the
binary is "in the repo" but we can't create a valid download URI for it
until it is actually in cloud storage.
The fix is implemented for 1.16. It is a low-risk change - a couple of
unit test changes and an additional check to see whether the blob ID exists
in both the S3 and Azure backend implementations.
-MR
Re: Backport OAK-7998 to 1.10.3
Posted by Matt Ryan <ma...@apache.org>.
Ah yes, I think that was a typo. Thanks Julian.
On Thu, Jul 18, 2019 at 2:14 AM Julian Reschke <ju...@gmx.de>
wrote:
> On 18.07.2019 02:06, Matt Ryan wrote:
> > Hi,
> >
> > I propose to backport the fix for OAK-7998 to 1.10.3.
> >
> > The issue in OAK-7998 is that it is possible to obtain a direct download
> > URI for a binary that doesn't exist in blob storage. While not usually
> > possible, this situation can arise if the binary in question was added
> via
> > addRecord() and then a download URI is immediately requested, if the
> binary
> > is in cache and is not yet uploaded to cloud storage. In such a case the
> > binary is "in the repo" but we can't create a valid download URI for it
> > until it is actually in cloud storage.
> >
> > The fix is implemented for 1.16. It is a low-risk change - a couple of
> > unit test changes and an additional check to see whether the blob ID
> exists
> > in both the S3 and Azure backend implementations.
> >
> >
> > -MR
>
> +1, but note that 1.10.3 was released last week. So it would be
> something for 1.10.4...
>
> Best regards, Julian
>
>
Re: Backport OAK-7998 to 1.10.3
Posted by Julian Reschke <ju...@gmx.de>.
On 18.07.2019 02:06, Matt Ryan wrote:
> Hi,
>
> I propose to backport the fix for OAK-7998 to 1.10.3.
>
> The issue in OAK-7998 is that it is possible to obtain a direct download
> URI for a binary that doesn't exist in blob storage. While not usually
> possible, this situation can arise if the binary in question was added via
> addRecord() and then a download URI is immediately requested, if the binary
> is in cache and is not yet uploaded to cloud storage. In such a case the
> binary is "in the repo" but we can't create a valid download URI for it
> until it is actually in cloud storage.
>
> The fix is implemented for 1.16. It is a low-risk change - a couple of
> unit test changes and an additional check to see whether the blob ID exists
> in both the S3 and Azure backend implementations.
>
>
> -MR
+1, but note that 1.10.3 was released last week. So it would be
something for 1.10.4...
Best regards, Julian