[WICKET-4490] Safari Version 5.1.5 (7534.55.3) AJAX update to include IResourceListener and CryptedUrlWebRequestCodingStrategy fails

• Type: Bug
• Status: Resolved
• Priority: Minor
• Resolution: Won't Fix
• Affects Version/s: 1.4.20
• Component/s: wicket
• Labels: ajax cryptedurlwebrequestcodingstrategy iresourcelistener safari
• Environment: MacOS Lion; Safari Version 5.1.5 (7534.55.3); Wicket 1.4.20
• Assignee: Unassigned
• Reporter: Nick Johnson
• Created: 05/Apr/12 22:43
• Updated: 10/Apr/12 12:10
• Resolved: 10/Apr/12 12:10

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.