Summary
The preflight check endpoint applies NFKC normalization to the incoming filename/folder name before checking for conflicts, but does not apply the same normalization to the names already stored in the folder. This causes an order-dependent, asymmetric 409 conflict for NFKC-equivalent names that can legitimately coexist as separate items.
Steps to reproduce
Take two names that are NFKC-equivalent but distinct code points:
- Item A: `\uFA1B` (CJK Compatibility Ideograph, U+FA1B)
- Item B: `\u798F` (CJK Unified Ideograph, U+798F)
These two items can coexist in Box — the actual upload/create endpoint accepts both. However:
Order 1 (succeeds):
1. Upload/create `\uFA1B` → stored as `\uFA1B` ✓
2. Upload/create `\u798F` → preflight normalizes `\u798F` → `\u798F`, no exact `\u798F` in folder → OK ✓
Order 2 (fails):
1. Upload/create `\u798F` → stored as `\u798F` ✓
2. Upload/create `\uFA1B` → preflight normalizes `\uFA1B` → `\u798F`, finds existing `\u798F` → **409 Conflict** ✗
This behavior is reproducible for both files (preflight check on OPTIONS https://api.box.com/2.0/files/content) and folders (create folder on POSThttps://api.box.com/2.0/folders).
Expected behavior
The preflight should either:
- Apply NFKC normalization symmetrically (normalize both the incoming name and all stored names before comparing), or
- Not apply NFKC normalization at all in the preflight, consistent with what the actual upload/create endpoint allows (better option in my opinion)
Actual behavior
The preflight normalizes only the incoming name (NFKC), producing a false conflict that depends entirely on creation order. The actual endpoint does not exhibit this behavior — both items can coexist when the preflight is bypassed.
Impact
Applications that rely on the preflight check cannot deterministically upload files or create folders with NFKC-equivalent names regardless of order, even though Box storage supports their coexistence.
I am using direct API requests without using any SDK.
If you need more details please let me know.