LDAP DirectoryControl 解析現在更嚴格

先前，.NET 使用 System.DirectoryServices.Protocols.BerConverter 來剖析它透過網路收到的 System.DirectoryServices.Protocols.DirectoryControl 物件，併產生它所傳送的 System.DirectoryServices.Protocols.DirectoryControl 位元組數位。 System.DirectoryServices.Protocols.BerConverter 使用 OS 特定的 BER 剖析功能。此剖析功能現在已在受控代碼中實作。

先前的行為

未檢查每個值的 ASN.1 標記。
剖析後的 DirectoryControl 末端的多餘資料則會被忽略，ASN.1 SEQUENCE 中的尾端數據也會同樣被忽略。
在Linux上，延伸超過其父序列結尾的 OCTET STRING 長度會傳回父序列以外的數據。
在舊版 Windows 上，傳回長度為零的 OCTET STRING null，而不是空字串。
將 System.DirectoryServices.Protocols.DirectoryControl 的內容讀取為 UTF8 編碼字串時，無效的 UTF8 序列不會擲回例外狀況。
將無效的 UTF-8 字串傳遞至 VlvRequestControl的構造函式時，未擲回例外。

雖然不是重大變更，但 Windows 一律以四位元組長度編碼 ASN.1 標籤，而 Linux 只會視需要針對標籤長度使用多少個字節。這兩個表示法都有效，但平臺之間的這種行為差異現在已消失;Linux 行為現在也會出現在 Windows 上。

DirectoryControl 解析更為嚴格，現在在各個平臺和版本中具有一致性：

現在會檢查 ASN.1 標記。
不再允許尾端數據。
現在會檢查 OCTET STRING和 SEQUENCE的長度。
長度為零的 OCTET STRING現在始終會返回空字串。
如果伺服器傳送無效的 UTF8 位元組序列，則 System.DirectoryServices.Protocols.DirectoryControl 剖析邏輯現在會擲回例外狀況，而不是以無訊息方式取代具有已知值的無效字元。

我們也會在呼叫 VlvRequestControl 建構函式時更徹底地驗證錯誤。傳遞無法編碼為 UTF8 值的字串現在會擲回 EncoderFallbackException。

.NET 10 Preview 1

這項變更是行為變更。

已針對 RFC 和規格合規性進行這項變更。在 MS-ADTS 的各種 RFC 和區段中，controlValue 被指定為 ASN.1 結構的 BER 編碼，具有類似於下列的措辭（摘自 RFC2891，第 1.2 節）：

controlType 設定為 “1.2.840.113556.1.4.474”。關鍵性為 FALSE（可能不存在）。 controlValue 是 OCTET STRING，其值為下列 SEQUENCE 值的 BER 編碼：

這排除了後端數據。它也排除了具有不同 ASN.1 標籤的 ASN.1 結構的 BER 編碼，以及無效的 BER 編碼（例如，OCTET STRING 長度超過其所屬 SEQUENCE 的情況）。

針對 VlvRequestControl 建構函式，提早擲回例外狀況表示使用者可以信任只有明確指定的值會傳送至伺服器。沒有任何情況會不小心將 EF BF BD 傳送至伺服器，因為它們已傳遞無法編碼為有效 UTF8 位元組的字串。

伺服器應符合 RFC 和規格。呼叫 VlvRequestControl 建構函式時，請務必處理 EncoderFallbackException。