You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Nick Johnson (Created) (JIRA)" <ji...@apache.org> on 2012/04/06 00:44:23 UTC
[jira] [Created] (WICKET-4490) Safari Version 5.1.5 (7534.55.3)
AJAX update to include IResourceListener and
CryptedUrlWebRequestCodingStrategy fails
Safari Version 5.1.5 (7534.55.3) AJAX update to include IResourceListener and CryptedUrlWebRequestCodingStrategy fails
----------------------------------------------------------------------------------------------------------------------
Key: WICKET-4490
URL: https://issues.apache.org/jira/browse/WICKET-4490
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4.20
Environment: MacOS Lion; Safari Version 5.1.5 (7534.55.3); Wicket 1.4.20
Reporter: Nick Johnson
In the case where we've seen this, we have a Form containing an AjaxButton. In the onSubmit of the AjaxButton, a second component implementing IResourceListener is made visible and is added to the page. This part works as expected.
The second component generates its src URL using urlFor(IResourceListener.INTERFACE);
This second component in turn contains a ByteArrayResource which would normally be handled in onResourceRequested. The component is one which would ordinarily be auto-fetched by the browser (in this case an embedded QuickTime object) after being added to the page, using the generated URL from its own urlFor().
In the case of Safari (and only Safari), however, the browser in turn attempts to fetch an encrypted URL which is invalid, causing an exception to be thrown: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher. It appears as though the URL is either getting mangled during adding of the component, or when the browser attempts to fetch the resource from the new component. (Will try to narrow down which it is.)
Unfortunately this one is a bit convoluted to reproduce...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4490) Safari Version 5.1.5 (7534.55.3)
AJAX update to include IResourceListener and
CryptedUrlWebRequestCodingStrategy fails
Posted by "Nick Johnson (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick Johnson updated WICKET-4490:
---------------------------------
Description:
In the case where we've seen this, we have a Form containing an AjaxButton. In the onSubmit of the AjaxButton, a second component implementing IResourceListener is made visible and is added to the page. This part works as expected.
The second component generates its src URL using urlFor(IResourceListener.INTERFACE);
This second component in turn contains a ByteArrayResource which would normally be handled in onResourceRequested. The component is one which would ordinarily be auto-fetched by the browser (in this case an embedded QuickTime object) after being added to the page, using the generated URL from its own urlFor().
In the case of Safari (and only Safari), however, the browser in turn attempts to fetch an encrypted URL which is invalid, causing an exception to be thrown: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher. It appears as though the URL is either getting mangled during adding of the component, or when the browser attempts to fetch the resource from the new component. (Will try to narrow down which it is.)
Unfortunately this one is a bit convoluted to reproduce...
Looking at what's going across the wire, it appears the problem is that the URL being fetched is wrong.
For a Page URL of http://localhost:8080/application/?x=BOEHPCGZAOHr2YfmZDrdDQ, and a urlFor result of ?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB... (truncated):
The AJAX response object creates the component on the page with the src attribute set to "?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...".
The incoming request from Safari, however, is GET /application/?x=BOEHPCGZAOHr2YfmZDrdDQ?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...
The incoming request from Chrome looks correct, GET /application/?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...
So this might also just be a Safari bug, though perhaps it could be worked around by generating an absolute URL to the IResourceListener instead of a relative one.
was:
In the case where we've seen this, we have a Form containing an AjaxButton. In the onSubmit of the AjaxButton, a second component implementing IResourceListener is made visible and is added to the page. This part works as expected.
The second component generates its src URL using urlFor(IResourceListener.INTERFACE);
This second component in turn contains a ByteArrayResource which would normally be handled in onResourceRequested. The component is one which would ordinarily be auto-fetched by the browser (in this case an embedded QuickTime object) after being added to the page, using the generated URL from its own urlFor().
In the case of Safari (and only Safari), however, the browser in turn attempts to fetch an encrypted URL which is invalid, causing an exception to be thrown: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher. It appears as though the URL is either getting mangled during adding of the component, or when the browser attempts to fetch the resource from the new component. (Will try to narrow down which it is.)
Unfortunately this one is a bit convoluted to reproduce...
> Safari Version 5.1.5 (7534.55.3) AJAX update to include IResourceListener and CryptedUrlWebRequestCodingStrategy fails
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-4490
> URL: https://issues.apache.org/jira/browse/WICKET-4490
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.20
> Environment: MacOS Lion; Safari Version 5.1.5 (7534.55.3); Wicket 1.4.20
> Reporter: Nick Johnson
> Labels: ajax, cryptedurlwebrequestcodingstrategy, iresourcelistener, safari
>
> In the case where we've seen this, we have a Form containing an AjaxButton. In the onSubmit of the AjaxButton, a second component implementing IResourceListener is made visible and is added to the page. This part works as expected.
> The second component generates its src URL using urlFor(IResourceListener.INTERFACE);
> This second component in turn contains a ByteArrayResource which would normally be handled in onResourceRequested. The component is one which would ordinarily be auto-fetched by the browser (in this case an embedded QuickTime object) after being added to the page, using the generated URL from its own urlFor().
> In the case of Safari (and only Safari), however, the browser in turn attempts to fetch an encrypted URL which is invalid, causing an exception to be thrown: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher. It appears as though the URL is either getting mangled during adding of the component, or when the browser attempts to fetch the resource from the new component. (Will try to narrow down which it is.)
> Unfortunately this one is a bit convoluted to reproduce...
> Looking at what's going across the wire, it appears the problem is that the URL being fetched is wrong.
> For a Page URL of http://localhost:8080/application/?x=BOEHPCGZAOHr2YfmZDrdDQ, and a urlFor result of ?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB... (truncated):
> The AJAX response object creates the component on the page with the src attribute set to "?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...".
> The incoming request from Safari, however, is GET /application/?x=BOEHPCGZAOHr2YfmZDrdDQ?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...
> The incoming request from Chrome looks correct, GET /application/?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...
> So this might also just be a Safari bug, though perhaps it could be worked around by generating an absolute URL to the IResourceListener instead of a relative one.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4490) Safari Version 5.1.5 (7534.55.3)
AJAX update to include IResourceListener and
CryptedUrlWebRequestCodingStrategy fails
Posted by "Nick Johnson (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick Johnson updated WICKET-4490:
---------------------------------
Priority: Minor (was: Major)
Description:
In the case where we've seen this, we have a Form containing an AjaxButton. In the onSubmit of the AjaxButton, a second component implementing IResourceListener is made visible and is added to the page. This part works as expected.
The second component generates its src URL using urlFor(IResourceListener.INTERFACE);
This second component in turn contains a ByteArrayResource which would normally be handled in onResourceRequested. The component is one which would ordinarily be auto-fetched by the browser (in this case an embedded QuickTime object) after being added to the page, using the generated URL from its own urlFor().
In the case of Safari (and only Safari), however, the browser in turn attempts to fetch an encrypted URL which is invalid, causing an exception to be thrown: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher. It appears as though the URL is either getting mangled during adding of the component, or when the browser attempts to fetch the resource from the new component. (Will try to narrow down which it is.)
Unfortunately this one is a bit convoluted to reproduce...
Looking at what's going across the wire, it appears the problem is that the URL being fetched is wrong.
For a Page URL of http://localhost:8080/application/?x=BOEHPCGZAOHr2YfmZDrdDQ, and a urlFor result of ?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB... (truncated):
The AJAX response object creates the component on the page with the src attribute set to "?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...".
The incoming request from Safari, however, is GET /application/?x=BOEHPCGZAOHr2YfmZDrdDQ?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...
The incoming request from Chrome looks correct, GET /application/?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...
So this might also just be a Safari bug, though perhaps it could be worked around by generating an absolute URL to the IResourceListener instead of a relative one.
Confirmed that using RequestUtils.toAbsolutePath() works around the issue with Safari 5.1.5.
was:
In the case where we've seen this, we have a Form containing an AjaxButton. In the onSubmit of the AjaxButton, a second component implementing IResourceListener is made visible and is added to the page. This part works as expected.
The second component generates its src URL using urlFor(IResourceListener.INTERFACE);
This second component in turn contains a ByteArrayResource which would normally be handled in onResourceRequested. The component is one which would ordinarily be auto-fetched by the browser (in this case an embedded QuickTime object) after being added to the page, using the generated URL from its own urlFor().
In the case of Safari (and only Safari), however, the browser in turn attempts to fetch an encrypted URL which is invalid, causing an exception to be thrown: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher. It appears as though the URL is either getting mangled during adding of the component, or when the browser attempts to fetch the resource from the new component. (Will try to narrow down which it is.)
Unfortunately this one is a bit convoluted to reproduce...
Looking at what's going across the wire, it appears the problem is that the URL being fetched is wrong.
For a Page URL of http://localhost:8080/application/?x=BOEHPCGZAOHr2YfmZDrdDQ, and a urlFor result of ?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB... (truncated):
The AJAX response object creates the component on the page with the src attribute set to "?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...".
The incoming request from Safari, however, is GET /application/?x=BOEHPCGZAOHr2YfmZDrdDQ?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...
The incoming request from Chrome looks correct, GET /application/?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...
So this might also just be a Safari bug, though perhaps it could be worked around by generating an absolute URL to the IResourceListener instead of a relative one.
> Safari Version 5.1.5 (7534.55.3) AJAX update to include IResourceListener and CryptedUrlWebRequestCodingStrategy fails
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-4490
> URL: https://issues.apache.org/jira/browse/WICKET-4490
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.20
> Environment: MacOS Lion; Safari Version 5.1.5 (7534.55.3); Wicket 1.4.20
> Reporter: Nick Johnson
> Priority: Minor
> Labels: ajax, cryptedurlwebrequestcodingstrategy, iresourcelistener, safari
>
> In the case where we've seen this, we have a Form containing an AjaxButton. In the onSubmit of the AjaxButton, a second component implementing IResourceListener is made visible and is added to the page. This part works as expected.
> The second component generates its src URL using urlFor(IResourceListener.INTERFACE);
> This second component in turn contains a ByteArrayResource which would normally be handled in onResourceRequested. The component is one which would ordinarily be auto-fetched by the browser (in this case an embedded QuickTime object) after being added to the page, using the generated URL from its own urlFor().
> In the case of Safari (and only Safari), however, the browser in turn attempts to fetch an encrypted URL which is invalid, causing an exception to be thrown: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher. It appears as though the URL is either getting mangled during adding of the component, or when the browser attempts to fetch the resource from the new component. (Will try to narrow down which it is.)
> Unfortunately this one is a bit convoluted to reproduce...
> Looking at what's going across the wire, it appears the problem is that the URL being fetched is wrong.
> For a Page URL of http://localhost:8080/application/?x=BOEHPCGZAOHr2YfmZDrdDQ, and a urlFor result of ?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB... (truncated):
> The AJAX response object creates the component on the page with the src attribute set to "?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...".
> The incoming request from Safari, however, is GET /application/?x=BOEHPCGZAOHr2YfmZDrdDQ?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...
> The incoming request from Chrome looks correct, GET /application/?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...
> So this might also just be a Safari bug, though perhaps it could be worked around by generating an absolute URL to the IResourceListener instead of a relative one.
> Confirmed that using RequestUtils.toAbsolutePath() works around the issue with Safari 5.1.5.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4490) Safari Version 5.1.5 (7534.55.3)
AJAX update to include IResourceListener and
CryptedUrlWebRequestCodingStrategy fails
Posted by "Martin Grigorov (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Grigorov resolved WICKET-4490.
-------------------------------------
Resolution: Won't Fix
> Safari Version 5.1.5 (7534.55.3) AJAX update to include IResourceListener and CryptedUrlWebRequestCodingStrategy fails
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-4490
> URL: https://issues.apache.org/jira/browse/WICKET-4490
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.20
> Environment: MacOS Lion; Safari Version 5.1.5 (7534.55.3); Wicket 1.4.20
> Reporter: Nick Johnson
> Priority: Minor
> Labels: ajax, cryptedurlwebrequestcodingstrategy, iresourcelistener, safari
>
> In the case where we've seen this, we have a Form containing an AjaxButton. In the onSubmit of the AjaxButton, a second component implementing IResourceListener is made visible and is added to the page. This part works as expected.
> The second component generates its src URL using urlFor(IResourceListener.INTERFACE);
> This second component in turn contains a ByteArrayResource which would normally be handled in onResourceRequested. The component is one which would ordinarily be auto-fetched by the browser (in this case an embedded QuickTime object) after being added to the page, using the generated URL from its own urlFor().
> In the case of Safari (and only Safari), however, the browser in turn attempts to fetch an encrypted URL which is invalid, causing an exception to be thrown: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher. It appears as though the URL is either getting mangled during adding of the component, or when the browser attempts to fetch the resource from the new component. (Will try to narrow down which it is.)
> Unfortunately this one is a bit convoluted to reproduce...
> Looking at what's going across the wire, it appears the problem is that the URL being fetched is wrong.
> For a Page URL of http://localhost:8080/application/?x=BOEHPCGZAOHr2YfmZDrdDQ, and a urlFor result of ?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB... (truncated):
> The AJAX response object creates the component on the page with the src attribute set to "?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...".
> The incoming request from Safari, however, is GET /application/?x=BOEHPCGZAOHr2YfmZDrdDQ?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...
> The incoming request from Chrome looks correct, GET /application/?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...
> So this might also just be a Safari bug, though perhaps it could be worked around by generating an absolute URL to the IResourceListener instead of a relative one.
> Confirmed that using RequestUtils.toAbsolutePath() works around the issue with Safari 5.1.5.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4490) Safari Version 5.1.5 (7534.55.3)
AJAX update to include IResourceListener and
CryptedUrlWebRequestCodingStrategy fails
Posted by "Martin Grigorov (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250592#comment-13250592 ]
Martin Grigorov commented on WICKET-4490:
-----------------------------------------
Wicket works with relative urls because otherwise it wont work at all behind reverse proxies.
1.4.x branch will receive only security fixes so this issue will not be investigated for now.
Please create a quickstart for 1.5.5 or 6.0.0-beta1 and we will reopen the ticket.
> Safari Version 5.1.5 (7534.55.3) AJAX update to include IResourceListener and CryptedUrlWebRequestCodingStrategy fails
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-4490
> URL: https://issues.apache.org/jira/browse/WICKET-4490
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.20
> Environment: MacOS Lion; Safari Version 5.1.5 (7534.55.3); Wicket 1.4.20
> Reporter: Nick Johnson
> Priority: Minor
> Labels: ajax, cryptedurlwebrequestcodingstrategy, iresourcelistener, safari
>
> In the case where we've seen this, we have a Form containing an AjaxButton. In the onSubmit of the AjaxButton, a second component implementing IResourceListener is made visible and is added to the page. This part works as expected.
> The second component generates its src URL using urlFor(IResourceListener.INTERFACE);
> This second component in turn contains a ByteArrayResource which would normally be handled in onResourceRequested. The component is one which would ordinarily be auto-fetched by the browser (in this case an embedded QuickTime object) after being added to the page, using the generated URL from its own urlFor().
> In the case of Safari (and only Safari), however, the browser in turn attempts to fetch an encrypted URL which is invalid, causing an exception to be thrown: javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher. It appears as though the URL is either getting mangled during adding of the component, or when the browser attempts to fetch the resource from the new component. (Will try to narrow down which it is.)
> Unfortunately this one is a bit convoluted to reproduce...
> Looking at what's going across the wire, it appears the problem is that the URL being fetched is wrong.
> For a Page URL of http://localhost:8080/application/?x=BOEHPCGZAOHr2YfmZDrdDQ, and a urlFor result of ?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB... (truncated):
> The AJAX response object creates the component on the page with the src attribute set to "?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...".
> The incoming request from Safari, however, is GET /application/?x=BOEHPCGZAOHr2YfmZDrdDQ?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...
> The incoming request from Chrome looks correct, GET /application/?x=Lw0rcH6imoxFoDyEeHQoSCXr5hSnV-54sDJPrlxB...
> So this might also just be a Safari bug, though perhaps it could be worked around by generating an absolute URL to the IResourceListener instead of a relative one.
> Confirmed that using RequestUtils.toAbsolutePath() works around the issue with Safari 5.1.5.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira