Hi,

I have emoji in my folder names (in order to replicate notion's folder icons), and from some initial testing, there seems to be some issue with that :

GET on /vault/filename

Yield to the following error in the obsidian console : node:internal/errors:464 Uncaught (in promise) TypeError: Invalid character in header content ["Content-Disposition"]

GET on /periodic/period

Yield the following error in the obsidian console :
TypeError: Invalid character in header content ["Content-Location"]

All request were done on the provided swagger UI, and all requests hangs instead of returning a 500 error, maybe that can also be a improvement ?

And I want to say, I love the idea of the plugin, there is soo much potential to be plugged to external tools, but since nearly all of my files are in a folder that contains a emoji name, I'm not able to use this plugin

Consider the following folder structure:

.
├── a
│   └── a.md
└── b

Request /vault/{filename} related endpoints with filename = a (a is a folder, not a valid file).

What I get from the server response: It's completely hung.

Similar results can get from GET, PUT, POST, DELETE endpoints.

What I expected to get from the server response:

It should return some errors instead of hanging (maybe 405 Bad Request?)

OS: MacOS Monterey 12.2.1 (M1) Obsidian version: 0.14.6 Obsidian local rest API version: 1.3.5

Thanks for the bug fixes in the latest release. However, the plugin install page can't work anymore. I'm not sure what problem it is since the developer console only shows 404 not found.

I suspect that there are two possible reasons:

1. The release branch name should be master instead of main according to the Official Release Guides. It seems that the setting of community-plugin repo doesn't specify branch property, so it uses the default branch setting (master). However, Github may redirect the master branch to the main branch, so I'm not sure whether this is the root cause.
2. The release name inconsistency. As mentioned in the latest release, there is no release version 1.3.7 in the Github repo, but the community plugin page shows that the latest version of the plugin is 1.3.7.

I use Obsidian 1.0.3 and Local rest api plugin.

I want my dailynotes in a subfolder per month : content/diary/YYYY/MM/DD.md

So today in content/diary/2022/12/04/md

But when I add a note from chrome using the extension configured with local API, my note is writen in content/diary/2017/12/04.dm (.dm is not a typo)

The obsidian core daily notes is configure this way : date format : YYYY/MM/DD new file location : content/diary

This is working fin in obsidian, I've the "Open daily note on startup check" and the right file is created at this moment.

This request has been raised a few different times over the last few months and I, too, see how this might be useful so I'm going to see about adding it as a new feature.

As of https://github.com/blacksmithgu/obsidian-dataview/issues/374#issuecomment-1152040331 it appears that obsidian-dataview now provides an accessible API for running dataview queries. Let's add support for using such queries for search.

An error report was received from @kaiiiz in #23:

I notice a related issue, for the PUT /vault/{filename} endpoint, if the specified folder in the path doesn't exist, the server will hang forever. (e.g. filename = c/d.md and folder c doesn't exist)

What I expected to get from the server response:

It should return 405 Bad Request or create the nested folder structure before creating the new file (maybe an optional parameter for this functionality?).

Originally posted by @kaiiiz in https://github.com/coddingtonbear/obsidian-local-rest-api/issues/23#issuecomment-1133943674

Consider the following folder structure:

.
├── a
│   └── a.md
└── b

What I get from the server response:

What I expected to get from the server response:

It should return 404 (Directory does not exist) instead of 200.

OS: MacOS Monterey 12.2.1 (M1) Obsidian version: 0.14.6 Obsidian local rest API version: 1.3.5

Consider the following folder structure:

.
├── a
│   └── a.md
└── b

What I get from the server response:

What I expected to get from the server response:

{
  "files": [
    "a/",
	"b/"
  ]
}

The server response should include the empty folder. I consider this as a bug since I'm implementing the function that chooses which directory should be used to create a new file, so all folders in the vault should be included in the response.

OS: MacOS Monterey 12.2.1 (M1) Obsidian version: 0.14.6 Obsidian local rest API version: 1.3.5

The mobile plug-in switch cannot be turned on [obsidian-local-rest-api] ，IOS Obsidian V1.2.0 is not supported. Hope the developer can solve it soon, thank you!

• Changing the value of Insecure HTTP Server Port seems to actually change the HTTPS port

• Note I've kept the HTTPS port default, but modified HTTP to 27125, while the dev console shows HTTP still at 27123 and HTTPS at 27125. Changing the Secure HTTPS Server Port value also modifies the actual HTTPS port.

• macOS 12.2.1

• Obsidian v0.13.33

If i GET a JPEG image file from my vault it seems to be getting corrupted. I am using python uplink module which is wrapping requests. I cannot save the file using the response.content, or recover the actual file from json content. Is the API assuming all files are markdown? Markdown files are working as expected. Thanks.

The patch method supports inserting content relative to a header if you send a request like:

PATCH /path/to/some/file.md HTTP/1.1
Content-Type: text/markdown
Heading: Some heading in your document
Content-Insertion-Position: end|beginning

Obsidian also supports block references, and those references are available via the CachedMetadata API. These would require slightly different headers, though:

• Block-Reference-Id: The ID of the block reference to insert content relative to.
• Content-Insertion-Position: Valid values before, on, after. The values after and on differ from one another in that that on will insert text immediately before the block reference marker on the same line as it, whereas after will insert on the next line.

Use of Heading and Block-Reference-Id in the same request or using a Content-Insertion-Position invalid for the provided reference (either Heading or Block-Reference-Id) will result in a 400 error.