几周前， Marco通过 Mastodon 联系了我，报告了Micro.publish 的问题。由于某种原因，他的一篇帖子未能发布，返回错误消息“无法获取”。最初我怀疑这可能与他的微博App Token有关。我建议他刷新博客列表并更新类别，看看会发生什么。这些行动效果很好。他还设法使用 Micro.publish 更新了该帖子；只是发布过程失败了。
昨天，Marco 又出现了同样的问题——发布周记时出现“无法获取”错误。这次，我要求 Marco 向我发送他试图发布的原始 Markdown 文件，以便我能够从我的端重现该问题。
重现问题很简单。对Obsidian控制台的检查显示，由于CORS 限制，网络请求被拒绝。
在 Obsidian 论坛上进行搜索后，我发现 Obsidian 有一种绕过 CORS 限制的网络请求替代方法。
不幸的是，将我的网络客户端切换为使用 Obsidian 的requestUrl()方法并没有像我希望的那样解决问题，但它确实指出了问题：网络请求的 URI 过长，导致HTTP Error 414 。
这个启示是有道理的。最初的实现使用了 Micropub 的 API，其中包含所有参数作为新帖子请求 URL 中的查询项。
为了更新帖子，在我的 Micro.publish 中，我使用 JSON 有效负载而不是查询项，因为这是 Micropub 处理更新的方法。鉴于 Micropub 还提供了用于发布新帖子的 JSON 选项，我决定使用它。
现在，发布和更新帖子都使用 JSON 有效负载而不是查询项。
作为参考，以下是新帖子的定义：
export type NewPostRequest = { 'type' : [ string ] 'mp-destination' : string 'properties' : { 'name' : [ string ] 'content' : [ string ], 'category' : [ string ], 'published' : [ string ], 'post-status' : [ string ] } }
type 、 name 、 content和其他字段都是字符串数组，这似乎很不寻常，但这种格式符合API 的要求。
提交 JSON 时，如下所示：
{ "type": [ "h-entry" ], "mp-destination": "otavio.cc" , "properties": { "name": [ "Title" ], "content": [ "This is the content." ], "category": [ "obsidian" , "example" , "hacking" ], "published": [ "2024-01-01T01:01:01-00:00" ], "post-status": [ "draft" ], } }
我将使用框架的fetch()而不是 Obsidian 的requestUrl()来维护当前的实现，因为切换到 JSON 似乎已经解决了该问题。但是，如果用户继续遇到“无法获取”错误，我可能需要重新访问并更新实现。
我要感谢Marco在隔离问题方面提供的帮助。他愿意提供原始 Markdown 文件，这对于我追踪并解决问题至关重要。
Micro.publish 2.3.2 更新将在接下来的几个小时内向所有用户推出。