Skip to content
New issue

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

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

Already on GitHub? # to your account

405 : Method Not Allowed when "save" #64

Open
manuel-masiello opened this issue Jun 11, 2020 · 3 comments
Open

405 : Method Not Allowed when "save" #64

manuel-masiello opened this issue Jun 11, 2020 · 3 comments

Comments

@manuel-masiello
Copy link

Hello,

I have an issue with this extension on JupyterHub + JupyterLab when I want to save the work.

The URL is : http://xx.xx.xx.xx:8000/save
405 : Method Not Allowed

Thx

@JeffSaxeVA
Copy link

JeffSaxeVA commented Jul 31, 2020

+1, I also have this issue. The installation of the extension went without apparent problems, including the build. I refreshed my Lab window, and now I have the ability to create a Diagram type, and all the drawing tools are working fine. Auto-Saves are also working, so my "untitled.dio" file is being occasionally updated in the file listing, and if I wait until it has saved and then close the tab for the drawing, it's fine, my drawing is preserved.

However, if I try to manually select Save or Save As, it brings up a small dialog asking me for a new filename (which, weirdly, suggests a .XML extension instead of .dio), and when I tell it to save, it optimistically alters its own title bar of the Lab browser window I'm in to have that new name, but then it pops opens a new (Chrome) browser tab out to the side, with a URL like https://MyJupyterHubServer/save, and with a 405 Method Not Allowed error.

So this feels like a URL construction bug... the code is seemingly trying to construct a POST URL, directed at itself or directed to a REST endpoint within its own code (which would cause a write-down to the .dio to happen), but instead, it's trying to target a "/save" endpoint of the very top of the site, which does not exist. Perhaps it's using an absolute path "/save" instead of a relative path "save" right in its same code / URL path...?

Note that this also affects the Export command, so I also cannot export the diagram as PNG or PDF. Presumably this is the same bug, just in two places in the code.

In case it helps, this is using The Littlest JupyterHub, current version, and then I have updated JupyterLab environment from the 1.2.x version that came with TLJH to the current 2.2.0 version. This is under Python 3.7 (the default used by TLJH). The bug happens whether I log into Lab using an admin or a non-admin account (for Hub purposes), and happens in both Chrome for Windows and Chrome for Mac.

Diving briefly into the code, the file lib/mxgraph/javascript/mxClient.js has a function around line 84406 called getUrlPost, which is supposed to return a URL to POST to, and it explicitly notes it will be used by the Save functionality. The default implementation seems to be returning a variable urlPost, which hopefully would be correct in any given environment, but maybe the construction of that variable (when the drawio document is first initialized) isn't working and it's coming out as an empty string...? Just a guess.

@orboan
Copy link

orboan commented Feb 27, 2021

I am suffering the same issue. This extension in a Jupyterhub + jupyterlab environment does not allow you to manually save the dio document neither to export it to any other format.
Jupyterhub is 1.3.0
Jupyterlab is 3.05

@hbcarlos
Copy link
Contributor

Hey, sorry for the delay we have been busy with other projects.
Using the save menu from the widget doesn't work. To save the diagram you'll have to use the button on Lab's menu bar.

We are working on a new PR with better integration with JupyterLab that removes both, toolbar and menu bar from the widget to have it on lab.

bollwyvl added a commit to bollwyvl/jupyterlab-drawio that referenced this issue Aug 8, 2021
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants