Multiline image links broken in (GitHub's) markdown

[sldblog]

It seems the multiline image links as mentioned in all the examples no longer work in GitHub's markdown files. (It does work if we use properly escaped URLs.)

https://github.com/TLmaK0/gravizo/blob/master/README.md

Same result with my browser extensions turned off.

[sldblog]

Apparently caused by https://githubengineering.com/a-formal-spec-for-github-markdown/, as per spec:

https://github.github.com/gfm/#link-destination

A link destination consists of either

• a sequence of zero or more characters between an opening < and a closing > that contains no spaces, line breaks, or unescaped < or > characters, or
• a nonempty sequence of characters that does not include ASCII space or control characters, and includes parentheses only if (a) they are backslash-escaped or (b) they are part of a balanced pair of unescaped parentheses.

Having newlines or spaces in link destinations is now considered invalid.

[TLmaK0]

I need to check but I think we should start to move to indirect way . Thanks @sldblog

[jeppefrandsen]

Have the same issue.

For our team I think the best would be to have a small command line tool for encoding/decoding the README.md since it would be difficult to use the indirect way with pull requests (URL pointing to file on branch).

[tralamazza]

maybe support URL encoded graph for the moment?

[TLmaK0]

URL encoded should works.

I know the problems with pull requests and indirect way :(, Could it be a solution try some kind of branch detection in github?

[jeppefrandsen]

Have made a small gravizo tool for being able to use gravizo with pull requests. It encodes/decodes GitHub Markdown files.

The idea is to e.g. use Atom for direct Markdown rendering, encode and upload to GitHub. For changing a file, decode it, change and encode again. We will try to use it within our team. A bit quickly made so only works with svg URLs, needs to end with "enduml)". Room for improvements ;)

[l2fprod]

@TLmaK0 in https://github.com/TLmaK0/gravizo/blob/master/README.md the links still point to the fix/README branch.

Is there an issue with caching and indirect way? Currently if I hit one graph I have (https://g.gravizo.com/source/extract_video?https%3A%2F%2Fraw.githubusercontent.com%2FIBM-Bluemix%2Fopenwhisk-darkvisionapp%2Fmaster%2FREADME.md) directly, I can see the graph correctly rendered but in the README.md (https://github.com/IBM-Bluemix/openwhisk-darkvisionapp) it is still showing an old version - one that did not render. Should gravizo set cache-control header on the response (and ETag)?

[TLmaK0]

@l2fprod this is something that I should check again, actually it returns cache-control: no-cache, but I don't know how github its handling the cache. Meanwhile you can add a ? at the end of the link to clear the cache.

[l2fprod]

@TLmaK0

Thank you. I don't see the cache-control header with curl or with Chrome inspector:

HTTP/1.1 200 OK
Date: Mon, 27 Mar 2017 09:50:10 GMT
Content-Type: image/png
Content-Length: 40290
Connection: keep-alive
Set-Cookie: __cfduid=deddddc7a8075741490608209; expires=Tue, 27-Mar-18 09:50:09 GMT; path=/; domain=.gravizo.com; HttpOnly
Server: cloudflare-nginx
CF-RAY: 341234baaf5231e-FRA

[TLmaK0]

@l2fprod you are right, I will review cloudflare configuration.

[TLmaK0]

@l2fprod I have added the cache-control for graphs in indirect way

[l2fprod]

@TLmaK0 thanks, that works, GitHub has refreshed the embedded graphs without me changing anything.

[svenevs]

I made a gist to help people who don't understand what urlencode means and they want to do the direct method. I don't personally find the process too difficult, but it depends on what your background is. Hope it helps somebody 😄

https://gist.github.com/svenevs/ce05761128e240e27883e3372ccd4ecd

[sldblog]

Seems like there are multiple tools to handle this kind of thing and it's unlikely that GitHub readme parsing will be relaxed.

I think this can be closed when

• GitHub readme is updated.
• https://gravizo.com is updated.

[svenevs]

If updating the samples on the homepage happens, it may be worth mentioning that this only breaks direct readme rendering on github. It still works elsewhere on github, e.g. I have a Jekyll site using kramdown and the gravizo direct method that still works. Maybe that will change, but the point is more that the direct method still works without urlencoding for markdown parsers that uhhhh... Aren't github.

[kofalt]

Just to chime in here, have you guys considered participating in the CommonMark spec discussion? It sounds like you have a pretty good use case for mutli-line links. The spec is currently in version 0.26, I imagine there's still room for adjustment :)

https://talk.commonmark.org

If someone ends up participating, leave a thread link. I'd be curious to see how it goes.