BUILD FAILURE: Jackrabbit Oak - Build # 1979 - Failure
The Apache Jenkins build system has built Jackrabbit Oak (build #1979) Status: Failure Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/1979/ to view the results. Changes: [reschke] OAK-8090: Update baseline comparisonVersion to 1.10.1 Test results: All tests passed<>
Re: Intent to backport OAK-8013
For reference: https://issues.apache.org/jira/browse/OAK-8013 On Wed, Feb 27, 2019 at 4:41 PM Matt Ryan wrote: > Hi, > > I would like to backport OAK-8013 to Oak 1.10. This change introduces a > workaround for an issue with the direct binary access code that is caused > by a bug in the Azure SDK. > > When a client requests a signed direct download URI, Oak includes a > specification in the signed URI to tell the service provider how it should > set the Content-Disposition on responses to requests for the signed URI. > The filename* portion of that header needs to be properly encoded, but the > Azure SDK does not handle this properly. This workaround prevents HTTP > clients from running into errors parsing the response headers due to an > improperly formatted filaneme* portion of the Content-Disposition header. > It is a temporary workaround until we can get a working solution in the > Azure SDK. > > The risk is low, it is limited only to direct binary download use cases, > and only applies to 1.10 and later. Please let me know if there are any > objections. > > > -MR > > >
Intent to backport OAK-8013
Hi, I would like to backport OAK-8013 to Oak 1.10. This change introduces a workaround for an issue with the direct binary access code that is caused by a bug in the Azure SDK. When a client requests a signed direct download URI, Oak includes a specification in the signed URI to tell the service provider how it should set the Content-Disposition on responses to requests for the signed URI. The filename* portion of that header needs to be properly encoded, but the Azure SDK does not handle this properly. This workaround prevents HTTP clients from running into errors parsing the response headers due to an improperly formatted filaneme* portion of the Content-Disposition header. It is a temporary workaround until we can get a working solution in the Azure SDK. The risk is low, it is limited only to direct binary download use cases, and only applies to 1.10 and later. Please let me know if there are any objections. -MR
BUILD FAILURE: Jackrabbit Oak - Build # 1974 - Failure
The Apache Jenkins build system has built Jackrabbit Oak (build #1974) Status: Failure Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/1974/ to view the results. Changes: [reschke] OAK-8051: PersistentCache: error during open can lead to incomplete initialization and subsequent NPEs - cleanup trailing whitespace in source code Test results: All tests passed<>
