← 2026-01-08 の一覧へ戻るホーム
WebDAVにおける数多くの困難

2026/01/08 0:50

WebDAVにおける数多くの困難

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

記事では、主要なサービスプロバイダーが公式標準にほとんど従わないため、WebDAV/CalDAV ライブラリを信頼性のあるものとして構築することは非実用的だと主張しています。これにより、多くの奇妙な挙動や臨時の回避策が生じます。

  1. go-webdav など既存の Go ライブラリは、サーバー側のコレクション同期など必須機能を欠いており、著者のデータモデルとも合致しません。
  2. RFC 2518、RFC 4918、および7つの拡張 RFC を検討しましたが、実用には複雑すぎてレガシー要素が多く重いと判明しました。
  3. WebDAV のスキーマが不明瞭であるため、著者は Apple CalendarDAVXThunderbird、Apple iCloud、Google Calendar、Radicale などの実際のクライアント／サーバーから HTTP トラフィックを逆解析し、プロキシや Wireshark を使用してリクエストボディとヘッダーを検査しました。
  4. Go の標準 XML ライブラリは不十分であったため、DOM 風に XML ノードを操作するカスタムラッパーを作成しました。
  5. MVP は既存サービスとの通信に成功したものの、Apple と Google が RFC の一部しか実装しておらず、一般的な応答しか返さないことが判明しました。
  6. CalDAV クライアントは大きく異なります：効率性を重視する場合はほとんどが sync-collection を使用すべきですが、Apple Calendar は ctags/etags に依存しています。
  7. 著者は主要プロバイダーの奇妙さと標準遵守に対する明確なドキュメントやサポート不足にフラストレーションを抱いています。
  8. オープンソースライブラリには、Google の特殊性など特定実装向けの回避策が頻繁に含まれています。

結論： 広範な非準拠とベンダー固有の奇妙さのため、WebDAV/CalDAV ライブラリを作成することは、理性を重視する人には推奨されません。

本文

標準は素晴らしい――それが破綻するとき

WebDAV／CalDAV クライアントとサーバーを実装するのは簡単そうに思えます。
2000 年代初頭に仕様化され、文書化も整っていて、ある程度広くサポートされています。
それが「ホームチャート」を作る際に最初に抱いた楽観的な前提です。

既存の Go 実装

NIH シンドロームを言及する前に、まず既存の Go 実装 go‑webdav を調べました。
そのライブラリは必要とした重要機能（サーバ側でのコレクション同期など）が不足しており、インターフェースも我々のデータモデルに合致しませんでした。
この機能がプロダクトの中核であるため、実装内容を自分たちで掌握することにしました。

クライアント／サーバー構築の出発点は？

  1. RFC を読む
    • RFC 2518（オリジナル）は RFC 4918 に置き換えられましたが、どこを採用すべきか詳細に掘り下げませんでした。
    • 拡張 RFC は全部で 7 本しかありません。

これらを読み進めると、我々が実装したいのは「カレンダーイベントの CRUD」のみだと判明しました。
RFC 全体を実装しようと試みてほぼ 1 ヶ月かけた結果、不要なレガシーコードが多すぎて諦めることに。

リバースエンジニアリング

RFC の基本的な理解を得た上で、既存のクライアント／サーバーをリバースエンジニアリングしました。
リクエストとレスポンスを観察するだけで、API を把握し、必要となるリクエスト/レスポンス種別を特定できました。

対象にしたクライアント／サーバー

クライアントサーバー
Apple CalendarApple iCloud
DavXThunderbirdGoogle Calendar
Radicale

HTTP プロキシや Wireshark を使ってトラフィックをキャプチャ。
WebDAV はヘッダーもボディも細部まで確認が必要なため、両方を解析しました。

Go で XML を扱う

Go のデフォルト XML ライブラリは実用的ではありませんでした。そこで、JavaScript が HTML 要素を操作するように XML ノードを管理できるラッパーを作成しました。

var davDisplayName = xmel.Element{
    Name:  "displayname",
    Space: davNS,
}
davDisplayName.SetValue("name")
n, err := davResponse.Find(davCollectionType)
davOwner = davOwner.AddChild(davHref.SetValue("http://example.com"))

WebDAV の「非構造化」スキーマが多いリクエスト/レスポンスでは、
このライブラリがマシャリング／アンマシャリングを簡潔に行える重要な要素でした。

標準はあくまで「提案」

MVP を完成させた後、既存実装と互換性テストを行いました。
多くの場合期待通り動作しましたが、時間が経つにつれて RFC から逸脱するケースが増えてきました。

プロバイダー備考
Apple / GoogleRFC の一部しか実装せず、サポート／省略情報を公開しない。WebDAV は HTTP レスポンスで機能を広告すべきだが、実際はそれを行わない。
クライアントCalDAV クライアントのリクエストスタイルは極めて多様。ほとんどは 
sync-collection
（効率的）を使うべきなのに、Apple Calendar は ctags と etags を使用。

大手プロバイダーが標準から逸脱したり独自の奇妙な実装を追加するケースはフラストレーションの源です。
非コンフォーマンスを訴えても「やめて」と言われ、法的措置を取る余地もありません。
同様の問題は他のオープンソースライブラリにも見られ、Google 仕様への回避策がコメントで散在しています。

結論

精神的安定を重視する方には、WebDAV／CalDAV ライブラリ作成は推奨できません。

同じ日のほかのニュース

一覧に戻る →

2026/01/08 5:16

Tailscale の状態ファイル暗号化は、もはやデフォルトでは有効になっていません。

2026/01/07 23:29

砂糖産業は研究者に影響力を行使し、脂質を心血管疾患（CVD）の原因として非難しました（2016年）

## Japanese Translation: --- ### 要約 2016年9月12日に *JAMA Internal Medicine* に掲載された研究は、糖業界と栄養科学者との長期にわたるパートナーシップを明らかにする340件の業界文書（1,582ページ）を調査しました。これらの文書は、1960年代半ばから始まった公衆および科学的関心をショ糖から食事脂肪へと移すための協力努力を示しています。 主な歴史的出来事は次の通りです： * **1954年** – 糖業界の貿易組織が低脂肪食の採用により1人当たりのショ糖消費量が3分の1以上増加すると予測しました。組織には30か国の加盟国がありました。 * **1965年** – ショ糖と心臓病リスクに関するメディア報道が急増し、業界はProject 226を委託しました。このプロジェクトはハーバード大学で文献レビューを行い、1967年に *The New England Journal of Medicine*（NEJM）に掲載されました。 Project 226 は糖業界からの資金（2016年換算で約50,000ドル）によって支援され、具体的な目的が設定され、記事が提供され、レビュー担当者（Roger Adams と D. Mark Hegsted）からドラフトが受領されましたが、NEJMの記事には資金源は明示されていませんでした。レビューの結論は、食事中のコレステロールを減らし飽和脂肪酸を多価不飽和脂肪酸に置き換えることで冠動脈心疾患を予防できるとした一方で、ショ糖関連研究を強く批判し食事脂肪の研究限界を無視しました。 UCSF の研究者は、科学的レビューが利益相反から自由であるべきであり、微妙な操作を避けるために完全な財務開示が必要だと強調しています。彼らは追加糖分と高血圧・心血管疾患との関連を示す証拠が増えているものの、現在の健康政策ではショ糖を心臓病リスク因子として一貫して引用していない点に注目しています。 **本研究への資金提供元は次のとおりです：** * UCSF Philip R. Lee Institute for Health Policy Studies * Hellmann Family Fund * UCSF School of Dentistry * National Institute of Dental and Craniofacial Research * National Cancer Institute 調査結果は、糖業界が歴史的に公衆の意見と科学的議論をどのように形成してきたかを示し、利益相反規則を強化することで規制当局・医療提供者・食品産業がシュガー表示、マーケティング慣行、および食事指針を再検討し、結果として製品中のショ糖含有量を低減させ消費者習慣に変化をもたらす可能性があることを示唆しています。

2026/01/07 13:40

「LMArena は AI にとっての悪性腫瘍です。」

## 日本語訳： （欠落している詳細を補完しつつ明確さを保ったもの） --- ## 要約 LMArena のリーダーボードは、事実の正確性よりも派手なフォーマット―太字ヘッダー、絵文字、長い回答―を報酬とするため、幻覚（hallucinations）を真実より優先させるゲーミフィケーション化されたベンチマークに変わってしまっています。500件の投票を分析した結果、52 % が誤りであり 39 % がユーザーの選択と強く相違していました。高得点を獲得した回答には、架空の「オズの魔法使い」の引用（例：作られたライン）や不可能な主張（例：9インチの丸パンが 9×13 インチの長方形パンと同じだと断言する）が含まれていました。Meta‑tuned Maverick モデルは、単純な「今何時？」という質問で太字テキスト、絵文字、回避的言語を駆使して勝利しました。 このシステムは未払いのボランティア労働に依存し、品質管理がほとんどないため、ユーザーは誤情報や捏造された情報を受け取ることが多く、特に医療文脈では非常に危険です。研究者・企業・AIコミュニティは LMArena を非公式な尺度として利用していますが、正確性重視の指標がない限り、モデルは引き続きエンゲージメントを優先し、信頼性よりも注目度を追求するため、広範囲にわたる誤情報と AI による意思決定支援への信頼低下を招くリスクがあります。

WebDAVにおける数多くの困難 | そっか～ニュース