Project

Profile

Help

Bug #4830

closed

HTML response from ixsl:schedule-action is parsed as XML, causing failure

Added by Michael Kay about 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Category:
IXSL extensions
Sprint/Milestone:
-
Start date:
2020-11-18
Due date:
% Done:

100%

Estimated time:
Applies to JS Branch:
2
Fix Committed on JS Branch:
2
Fixed in JS Release:
SEF Generated with:
Platforms:
Company:
-
Contact person:
-
Additional contact persons:
-

Description

(Reported by Martynas Jusevičius on saxon-help mailing list on 2 Nov 2020).

Saxon receives an HTTP response with content type text/html and attempts to parse it as XML, causing a failure FODC0002.

In this particular case it's an error response with HTTP status 400, but I think the same failure could occur on a success response.

At BrowserPlatfform.js line 393 we do

case "text/html":
                            // HTML types
                            response.body = http.responseXML || parse(http.responseText);
                            break;

where parse() is invoking the XML parser. This looks incorrect.

Actions #1

Updated by Michael Kay about 4 years ago

According to https://stackoverflow.com/questions/10585029/parse-an-html-string-with-js we should be doing

new DOMParser().parseFromString(html, "text/html");

or perhaps we should be calling our existing parseXmlFromString() method with a second parameter giving the media type, which would have the same effect.

Actions #3

Updated by Norm Tovey-Walsh almost 4 years ago

  • Status changed from New to In Progress
  • Assignee changed from Michael Kay to Norm Tovey-Walsh
Actions #4

Updated by Community Admin almost 4 years ago

  • Applies to JS Branch 2 added
  • Applies to JS Branch deleted (2.0)
Actions #5

Updated by Norm Tovey-Walsh almost 4 years ago

  • Status changed from In Progress to Resolved

This has been fixed. Any text/html response will now be parsed with the HTML parser.

Actions #6

Updated by Debbie Lockett almost 4 years ago

  • Status changed from Resolved to In Progress

Reopening as I'm seeing some new failures for fn-transform tests in the browser (e.g. fn-transform-4), which look to be caused by the changes. The Platform.parseXmlFromString method already has a second argument (lineNumbering) defined for the NodePlatform, so we're now sometimes getting a conflict.

Actions #7

Updated by Debbie Lockett almost 4 years ago

  • Status changed from In Progress to Resolved

Further fixes committed, so that parseXmlFromString now has 3 consistent arguments.

Actions #8

Updated by Debbie Lockett over 3 years ago

  • Fix Committed on JS Branch 2 added
Actions #9

Updated by Debbie Lockett over 3 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in JS Release set to Saxon-JS 2.1

Bug fix applied in the Saxon-JS 2.1 maintenance release.

Please register to edit this issue

Also available in: Atom PDF Tracking page