Protocol Relative URL's cause ProtocolInvalidOperationError

[halfnibble]

Using a protocol relative URL in HTML source code, for example:
<link href='//fonts.googleapis.com/css?family=Permanent+Marker' rel='stylesheet' type='text/css'>
causes an exit status 1, ProtocolInvalidOperationError.

Perhaps wkhtmltopdf could be modified to assume a smart default protocol (http or https) when the protocol is relative?

Thanks.

[channainfo]

i have the same problem with relative protocol

[bgadoury]

This is a duplicate of #1746

[halfnibble]

Interesting. It does appear to be a duplicate. I didn't catch that because the other issue is marked as "closed." However, this issue persists even in the most recent build.

[bocharsky-bw]

Well, it's not a duplicate. All previous issues were solved by specifying a protocol, but it's just a workaround. Maybe let's fix it finally? Links that start with // are valid links, so looks like it's a bug.

[marcusorjames]

Has this been put on the roadmap at all due to the constraints of the system I am working with it's a real pain to have to convert everything to not use protocol relative urls

[nuest]

I use a third party template and ran into the same error. Since I already had a make target to run wkhtmltopdf I added the following two preprocessing steps, hope it helps someone coming across this issue:

find site/ -type f -name '*.html' | xargs sed -i 's|href="//|href="https://|g'
find site/ -type f -name '*.html' | xargs sed -i 's|src="//|src="https://|g'

[PhilterPaper]

The proper fix is to remember whether the source page was invoked under http: or https:, and use that. If you blindly add "https:" to a URL, you run the risk of the target server not supporting SSL, or that you'll get a 30x response requesting another try with an updated URL. @nuest's fix is at best a workaround when you know that all such URLs can be http: or https:, but I wouldn't use it as a general fix.

[igordeveloper]

#5274 i have the same problem