Parsoid gives VisualEditor insecure content when using HTTPS (should use protocol-relative URLs)
Closed, ResolvedPublic

Description

When I go to https://en.wikipedia.org/wiki/User:Trevor_Parscal and click the "visualeditor" tab, my browser console says:


The page at https://en.wikipedia.org/wiki/User:Trevor_Parscal displayed insecure content from http://en.wikipedia.org/w?title=Special:FilePath/California_Bay_Area_county_map.svg&width=.

Consequently, the pretty green lock icon in Google Chrome turns yellow.


Version: unspecified
Severity: major

bzimport added a project: Parsoid.Via ConduitNov 22 2014, 1:08 AM
bzimport set Reference to bz43015.
MZMcBride created this task.Via LegacyDec 12 2012, 3:46 PM
Catrope added a comment.Via ConduitDec 12 2012, 7:03 PM

Upstream Parsoid bug: bug 42976

Jdforrester-WMF added a comment.Via ConduitJan 7 2013, 5:15 PM

Tagging with deploy-train cycle.

Eloquence added a comment.Via ConduitJun 18 2013, 4:50 AM

I am getting this issue, on the test page referenced in the bug and others, again. The URLs do not contain Special:FilePath anymore, so perhaps something was changed about how images are handled that introduced a regression? Reopening this bug since the issue appears to be essentially the same.

Jdforrester-WMF added a comment.Via ConduitJun 18 2013, 5:25 PM
  • Bug 49283 has been marked as a duplicate of this bug. ***
Catrope added a comment.Via ConduitJun 18 2013, 7:22 PM

This seems to have been unfixed in production.

Strangely, parsoid.wmflabs.org is now giving me https URLs for images.

Catrope added a comment.Via ConduitJun 19 2013, 12:52 AM

(In reply to comment #7)

This seems to have been unfixed in production.

Specifically, Parsoid is now once again returning http:// URLs for images (except in labs, where it returns https:// URLs). MZ submitted a fix in December to make these URLs protocol-relative, but this seems to have been unfixed somehow.

Perhaps the repository URL is being grabbed from the API? That would explain why it's now a fully qualified URL, and it might explain the difference between labs and production.

Jdforrester-WMF added a comment.Via ConduitJun 19 2013, 12:57 AM

Per Roan's comments, moving to Parsoid so they can fix.

GWicke added a comment.Via ConduitJun 19 2013, 1:04 AM

We used to use a special page redirect hack, but now use the API to properly retrieve image information including the path. So the new code needs to implement some similar protocol-relative massaging for image URLs, at least for the domains we know to support both http and https.

Jdforrester-WMF added a comment.Via ConduitJun 21 2013, 10:50 PM
  • Bug 49984 has been marked as a duplicate of this bug. ***
gerritbot added a comment.Via ConduitJun 24 2013, 11:11 PM

Related URL: https://gerrit.wikimedia.org/r/70344 (Gerrit Change I253b9b7a9b463439e86d7cf7975cd92f9c851e70)

gerritbot added a comment.Via ConduitJun 24 2013, 11:38 PM

Related URL: https://gerrit.wikimedia.org/r/70348 (Gerrit Change Ied95c87fda13dbea2b8c46ad1e96fde1c50c1517)

gerritbot added a comment.Via ConduitJun 25 2013, 12:13 AM

https://gerrit.wikimedia.org/r/70348 (Gerrit Change Ied95c87fda13dbea2b8c46ad1e96fde1c50c1517) | change APPROVED and MERGED [by jenkins-bot]

GWicke added a comment.Via ConduitJun 25 2013, 12:20 AM

The fix will go out with tomorrow's Parsoid deployment.

gerritbot added a comment.Via ConduitJun 25 2013, 12:20 AM

https://gerrit.wikimedia.org/r/70344 (Gerrit Change I253b9b7a9b463439e86d7cf7975cd92f9c851e70) | change APPROVED and MERGED [by jenkins-bot]

Aklapper added a comment.Via ConduitJul 4 2013, 10:34 AM

[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704]

Add Comment