#1878 closed defect (fixed)
NS_ERROR_MALFORMED_URI when accessing EBSCO via proxy
| Reported by: | ajlyon | Owned by: | simon |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | ingester | Version: | |
| Keywords: | Cc: |
Description
There's a report on the forums of this error:
[JavaScript Error: "[Exception... "Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIIOService.newURI]" nsresult: "0x804b000a (NS_ERROR_MALFORMED_URI)" location: "JS frame :: chrome://zotero/content/xpcom/proxy.js :: <TOP_LEVEL> :: line 316" data: no]" {file: "file:///Users/ed/Library/Application%20Support/Firefox/Profiles/ife062iq.default/zotero/translators/EBSCOhost.js" line: 0}]
My thought was that this is being caused by presence of fragment identifiers (#..) in the URLs, but that doesn't seem to be the case. I'm not sure what's happening, but it seems to me that it shouldn't be possible for translators to trigger errors like this using ordinary doGet/processDocuments calls.
Change History (3)
comment:1 Changed 5 years ago by simon
- Resolution set to fixed
- Status changed from new to closed
comment:2 Changed 5 years ago by simon
It certainly shouldn't be possible for a translator to trigger an error like this. Based on the error and what the code was doing before r10026, I think there was a bug that would have prevented relative URIs from being resolved properly when a proxy is in use.
comment:3 Changed 5 years ago by ajlyon
The user confirmed that the 2.1 branch, with this patch, fixed his issue. Thanks for the quick response.
In [10026]: