New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Images in subpages named index.md have the incorrect path on Windows/cygwin #842

Closed
styfle opened this Issue Feb 25, 2016 · 34 comments

Comments

Projects
5 participants
@styfle
Contributor

styfle commented Feb 25, 2016

I am using the following markdown in index.md and running mkdocs serve

## Diagram
This is the svg
![svg](diagram.svg)

The output is correct

<img alt="svg" src="./diagram.svg" /></p>

However I get a broken image as seen below

image

It appears that the svg file is served as application/octet-stream instead of the expected image/svg+xml

@d0ugal

This comment has been minimized.

Member

d0ugal commented Feb 25, 2016

Interesting. Can you try with this option and let me know if that solves the svg issue?

mkdocs serve --no-livereload
@styfle

This comment has been minimized.

Contributor

styfle commented Feb 25, 2016

@d0ugal I tried and it does not solve the issue.

@d0ugal

This comment has been minimized.

Member

d0ugal commented Feb 26, 2016

Interesting, I tried with a random SVG I found online and the response headers stated Content-Type:image/svg+xml but the image was still broken. This happened with and without livereload enabled.

@d0ugal

This comment has been minimized.

Member

d0ugal commented Feb 26, 2016

Ah, I tried again with another SVG file and it worked fine with and without livereload. The content type was correct and the image rendered.

Can you let me know your mkdocs version? Either with mkdocs --version or pip freeze | grep mkdocs

@waylan

This comment has been minimized.

Member

waylan commented Feb 26, 2016

As livereload is a simple wrapper around tordano's static file server, I checked and tordano seems to only ever have had one relevant issue filed regarding SVG (tornadoweb/tornado#1637). And according to that issue, SVG files have always been served as image/svg+xml. Not sure why any would be served as application/octet-stream. All that PR did was add SVG to the list of types that get GZip compression and it appears to have not made it into a release yet. And livereload has never had any SVG related issues filed.

@styfle all I can suggest is to make sure you are using the latest release of livereload, tornado, and MkDocs.

@d0ugal

This comment has been minimized.

Member

d0ugal commented Feb 26, 2016

Yeah, my best guess is that it is a really old MkDocs from when we hacked together out own server.

@styfle

This comment has been minimized.

Contributor

styfle commented Feb 26, 2016

@d0ugal @waylan I'm using the latest as far as I can tell.

$ python --version
Python 2.7.10

$ pip --version
pip 8.0.2 from /usr/lib/python2.7/site-packages (python 2.7)

$ mkdocs --version
mkdocs, version 0.15.3
@styfle

This comment has been minimized.

Contributor

styfle commented Feb 26, 2016

I'm running on Windows 10 with Cygwin.
Here is the pip packages which might be useful.
It looks like the latest version of tornadoweb.

$ ls -lA /usr/lib/python2.7/site-packages
total 412
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 11:33 _markerlib
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 alabaster
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 alabaster-0.7.7.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 babel
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 Babel-2.2.0.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 backports
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 backports.ssl_match_hostname-3.5.0.1.dist-info
-rw-r--r--  1 styfle Domain Users  5277 Feb 24 13:23 backports_abc.py
-rw-r--r--  1 styfle Domain Users  6564 Feb 24 13:23 backports_abc.pyc
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 backports_abc-0.4.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 certifi
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 certifi-2015.11.20.1.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 click
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 click-6.3.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 14:40 CommonMark
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 14:40 CommonMark-0.5.4.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 11:57 django
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 11:57 Django-1.9.2.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 docutils
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 docutils-0.12.dist-info
-rw-r--r--  1 styfle Domain Users   126 Feb 24 11:33 easy_install.py
-rw-r--r--  1 styfle Domain Users   315 Feb 24 11:33 easy_install.pyc
-rw-r--r--  1 styfle Domain Users   226 Feb 24 11:47 easy-install.pth
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 jinja2
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 Jinja2-2.8.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 livereload
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 livereload-2.4.1.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 markdown
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 Markdown-2.6.5.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 markupsafe
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 MarkupSafe-0.23.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 mkdocs
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 mkdocs_bootstrap
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 mkdocs_bootstrap-0.1.1.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 mkdocs_bootswatch
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 mkdocs_bootswatch-0.3.1.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 mkdocs-0.15.3.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 11:33 pip
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 11:33 pip-8.0.2.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 11:33 pkg_resources
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 pygments
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 Pygments-2.1.1.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 pytz
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 pytz-2015.7.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 PyYAML-3.11.dist-info
-rw-r--r--  1 styfle Domain Users   119 Jun  1  2015 README
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 11:47 readthedocs-1.0-py2.7.egg
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 14:40 recommonmark
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 14:40 recommonmark-0.4.0.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 11:33 setuptools
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 11:33 setuptools-20.1.1.dist-info
-rw-r--r--  1 styfle Domain Users  8292 Feb 24 13:23 singledispatch.py
-rw-r--r--  1 styfle Domain Users  8023 Feb 24 13:23 singledispatch.pyc
-rw-r--r--  1 styfle Domain Users  5228 Feb 24 13:23 singledispatch_helpers.py
-rw-r--r--  1 styfle Domain Users  8574 Feb 24 13:23 singledispatch_helpers.pyc
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 singledispatch-3.4.0.3.dist-info
-rw-r--r--  1 styfle Domain Users 30098 Feb 24 12:02 six.py
-rw-r--r--  1 styfle Domain Users 29545 Feb 24 12:02 six.pyc
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 six-1.10.0.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 snowballstemmer
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 snowballstemmer-1.2.1.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 sphinx
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 sphinx_rtd_theme
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 sphinx_rtd_theme-0.1.9.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 12:02 Sphinx-1.3.5.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 tornado
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 tornado-4.3.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 11:33 wheel
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 11:33 wheel-0.29.0.dist-info
drwxr-xr-x+ 1 styfle Domain Users     0 Feb 24 13:23 yaml
@d0ugal

This comment has been minimized.

Member

d0ugal commented Feb 26, 2016

Interesting. Then my new best guess is that this is Windows related. All the versions you are using otherwise are known to be good o think.

@waylan

This comment has been minimized.

Member

waylan commented Feb 26, 2016

I just tried this on Windows 7 and was not able to reproduce the problem.

I got the following response (which works fine):

HTTP/1.1 200 OK
Date: Fri, 26 Feb 2016 17:09:09 GMT
Content-Length: 10009
Etag: "eb2a8759ddf38da50f60feb11f7208f5ec11daac"
Content-Type: image/svg+xml
Server: TornadoServer/4.1

And I have the following installed:

livereload==2.3.2
tornado==4.1
mkdocs==0.15.3
@d0ugal

This comment has been minimized.

Member

d0ugal commented Feb 29, 2016

Hmm, odd. @styfle Have you tried this with a different SVG file just to ceck it isn't broken?

@styfle

This comment has been minimized.

Contributor

styfle commented Feb 29, 2016

@d0ugal @waylan
You know, my initial post was incorrect. I said that <img alt="svg" src="./diagram.svg" /></p> is the correct output when in fact the output should be the relative path <img alt="svg" src="diagram.svg" /></p>

Is my markdown wrong? What's the proper way to include an image relative to the current md file?

@waylan

This comment has been minimized.

Member

waylan commented Feb 29, 2016

What happens when you try to load the URL for the SVG file directly? Try going directly to http://127.0.0.1:8000/diagram.svg. Does that work properly?

It should simply display your SVG file in the browser. If it does anything else, then the problem is with the SVG file. If it works fine, then the problem is something else.

@waylan

This comment has been minimized.

Member

waylan commented Feb 29, 2016

Oh and so I don't forget, I looked a little closer at what Tornado is doing to determine mime types. It is using the Python standard library function mimetypes.guess_type. However, if the [encoding is not None'](https://github.com/tornadoweb/tornado/blob/master/tornado/web.py#L2560), then application/octet-streamis used. If you are gettingapplication/octet-streamas the mime type, then check whatmimetypes.guess_typeis returning as the encoding for your SVG file. If it is returning anything other thanNone, then the problem is with your SVG file. Note the comments in the Python docs about encoding. By my reading, it should be returning None` for the encoding, in which case Tornado would return the proper type.

@styfle

This comment has been minimized.

Contributor

styfle commented Feb 29, 2016

@waylan
The file is not in the root directory--its under infrastructure. My original post is the source of the /infrastructure/index.md file.

I visited http://127.0.0.1:8000/infrastructure/ and the html looks fine except the image. Visiting http://127.0.0.1:8000/infrastructure/diagram.svg downloads the file and visiting http://127.0.0.1:8000/diagram.svg is a 404 because the file is not there.

I believe the problem is with your markdown parser assuming the images are at the root.
Given the same markdown input, the CommonMark Dingus produces the expected html with the image relative to the current file:

<h2 data-sourcepos="1:1-1:10">Diagram</h2>
<p data-sourcepos="2:1-3:19">This is the svg
<img src="diagram.svg" alt="svg" /></p>

The mkdocs html is wrong in my opinion, and produces image relative to the root directory:

<h2 id="diagram">Diagram</h2>
<p>This is the svg
<img alt="svg" src="./diagram.svg" /></p>
@waylan

This comment has been minimized.

Member

waylan commented Feb 29, 2016

Ok, this is definitely a URL/path related issue. MkDocs does its own thing with internal links (overriding Markdown's default behavior) and it appears that you have found a broken edge case. Neither @d0ugal (AFAICT) or myself considered that as a possibility due to you reporting an incorrect content type.

@d0ugal

This comment has been minimized.

Member

d0ugal commented Feb 29, 2016

Damn, yet another time that I wish we didn't rename Markdown files to filename/index.html.

@waylan

This comment has been minimized.

Member

waylan commented Feb 29, 2016

Damn, yet another time that I wish we didn't rename Markdown files to filename/index.html.

May I suggest lepture/python-livereload#131. No indication as to whether it will be accepted (if not we could always do our own subclass). And it would be a backward incompatible change (it would break existing third-party links to MkDocs sites), but it certainly solves these sorts of problems. @d0ugal, if you are interested, I can write up a full proposal as a separate issue.

@waylan

This comment has been minimized.

Member

waylan commented Feb 29, 2016

@styfle If it is not important to you, a workaround may be to disable use_directory_urls. In your config file set use_directory_urls=false. That way the HTML document will be in the same directory as the SVG file and MkDocs won't (shouldn't) mess with the URL of the SVG file. Of course, you loose the so-called "pretty" URLs. All your pages' URLs will require the extension in the name. In order words, the page would be at http://127.0.0.1:8000/infrastructure.html instead of http://127.0.0.1:8000/infrastructure/.

@styfle

This comment has been minimized.

Contributor

styfle commented Feb 29, 2016

@waylan Yes use_directory_urls=false works for me 👍
It's not ideal but its better to have it working, thanks!

I should have told you my folder structure. Here it is:

/
    mkdocs.yml
    /docs
        about.md
        /infrastructure
            diagram.svg
            index.md           ## this was the file I displayed the source in original post
@waylan

This comment has been minimized.

Member

waylan commented Feb 29, 2016

I should have told you my folder structure. Here it is:

Ah, that explains the bug better. Thank you. Because this page is an index page to begin with, MkDocs should not be rewriting the SVG URL. It appears that it is anyway.

@d0ugal

This comment has been minimized.

Member

d0ugal commented Feb 29, 2016

We have had problems with index.md files before. I thought I fixed them all. Seems not.

@d0ugal d0ugal added Bug and removed Needs information labels Feb 29, 2016

@d0ugal d0ugal changed the title from mkdocs serve does not work well with svg to Images in subpages have the incorrect path (and thus wont load) Mar 1, 2016

d0ugal added a commit to d0ugal/mkdocs that referenced this issue Mar 1, 2016

@d0ugal

This comment has been minimized.

Member

d0ugal commented Mar 1, 2016

I added a test project in #852 that tests every combination of sub pages and referencing images that I could think of. They all work fine for me, so I think this is a Windows specific occurrence of the old index.md bug we have seen before.

To test it I just change into the subpages directory and run mkdocs serve. It will be built with a tox run also and can be found in the env tmp dirs.

@d0ugal d0ugal changed the title from Images in subpages have the incorrect path (and thus wont load) to Images in subpages names index.md have the incorrect path on Windows Mar 1, 2016

@styfle

This comment has been minimized.

Contributor

styfle commented Mar 1, 2016

I think this is a Windows specific occurrence

Yes is probably is windows specific. I realized that installing python with cygwin makes the system think its *nix and works for most things, however installing python directly in windows behaves a little differently, especially how paths are referenced.

My workaround at this point is to create a /static/ folder in the root for all images and then stop using index.md as a file name.

@d0ugal

This comment has been minimized.

Member

d0ugal commented Mar 2, 2016

I'm glad you have been able to figure out a workaround for now. I'm not sure how to progress with this bug, I'll have a think.

@waylan

This comment has been minimized.

Member

waylan commented Mar 2, 2016

I suspect the problem is that when (windows installed) Python is run from cygwin, it does not report itself as being on Windows. Or at least some variation of that problem.

@d0ugal d0ugal modified the milestone: 0.16 Apr 27, 2016

@waylan waylan changed the title from Images in subpages names index.md have the incorrect path on Windows to Images in subpages named index.md have the incorrect path on Windows/cygwin Aug 17, 2016

@waylan

This comment has been minimized.

Member

waylan commented Aug 17, 2016

@styfle its not clear to me, but are you using Windows Python from cygwin or cygwin Python?

@styfle

This comment has been minimized.

Contributor

styfle commented Aug 17, 2016

@waylan I was using cygwin python package on my local machine and Windows Python on the server which explains why I was getting different results in each environment.

@waylan waylan modified the milestones: 1.0.0, 0.16 Nov 17, 2016

@sergiomcalzada

This comment has been minimized.

sergiomcalzada commented May 22, 2017

Any news on that bug? In windows 10 the paths are wron in mac the paths are correct :(

@waylan

This comment has been minimized.

Member

waylan commented May 22, 2017

Unfortunately, none of the maintainers have access to a Windows machine with a cygwin environment. Therefore, it is difficult for us to debug this. My guess is that some code is checking which system MkDocs is running on and then doing something different with the paths. I assume that the problem is that in cygwin, it is (incorrectly) seeing Windows as a *nix system (Mac, Linux, Unix, etc). But without the ability to confirm the problem, we are unsure of how to fix it.

Any debugging help, patches, and/or pull requests are welcome and would move this along.

As @styfle noted above, as a workaround, you can use Windows Python rather than cygwin Python to avoid the problem.

@sergiomcalzada

This comment has been minimized.

sergiomcalzada commented May 22, 2017

I don't know the diference between versions. Just donwloaded v3.6/2.7 from python website. Could you tell me how to download "windows python" version?

Thanks.

@waylan

This comment has been minimized.

Member

waylan commented May 22, 2017

If you don't know what cygwin is, then you almost certainly do not have is installed (its a Linux environment that runs inside Windows). That being the case, you have a different problem than what is being reported/discussed here. Please open a new issue with enough info to replicate your problem.

@sergiomcalzada

This comment has been minimized.

sergiomcalzada commented May 23, 2017

I know that cygwin is a compiler... so when you said Windows Python/cygwin Python I thought that should be different "python compiled versions" (I dont know how python is generated/compiled/executed).

At the end, cygwind Phyton is to run "mkdocs" in "ubuntu in windows" (or something similar). I will try it and see if it works

@d97ulf

This comment has been minimized.

d97ulf commented Sep 20, 2017

I stumbled upon this ticket while trying to get MkDocs to serve SVG files in a Docker container. I just wanted to add to the record that it seems like the Python mimetypes module is looking in certain predefined places for a "mime.types" file - e.g. /etc/mime.types or /etc/httpd/mime.types. It is strange that it does not supply its own file, but obviously that's how it is implemented...

Since my Docker image is a minimalistic image based on Alpine Linux, there were no mime.types files. After installing the "mailcap" package containing the /etc/mime.types file, the SVG files are now served by MkDocs in the correct way.

I guess this could be the case when running in cygwin on Windows as well. If /etc/mime.types is missing, you will end up with octet-streams for SVGs.

@waylan waylan added this to To do in Pages Refactor Feb 5, 2018

@waylan waylan moved this from To do to In progress in Pages Refactor Jun 8, 2018

@waylan waylan closed this in 34ef3ca Jun 28, 2018

Pages Refactor automation moved this from In progress to Done Jun 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment