KQL addresses an open extension property as extensions.<name>.<property>.
The literal picks the typed sibling: a number or date-time range asks the
number or date sibling, an equality asks every sibling the literal fits
(the lowercased string, and the number, boolean or date it also reads
as), = asks the string as written. Both compilers build the same plan.
The parity suite covers the queries and the lifecycle of extensions
through re-typing, removal, move and trash.
Every property of an open extension is indexed under the sibling of its
value's kind (ext.<name>.<property>.@keyword/@lower/@number/@bool/@date/
@geo), so a property can change its kind between writes without a
mapping change. bleve builds the fields directly and indexes them with
IndexAdvanced, the mapping stays as it is; OpenSearch types them through
dynamic templates under a dynamic ext object, which the reconciler
compares by rule instead of by concrete field. The stored values travel
with the document so Move, Delete and Restore keep the extensions.
The search service follows ArbitraryMetadataUpdated events that touch an
extension.
Adds the openTypeExtension collection of a driveItem under
/v1beta1/drives/{drive-id}/items/{item-id}/extensions: list, get, upsert
(merge, null removes) and delete, plus $expand=extensions on the item.
Every property is one arbitrary metadata key, so an upsert writes and
removes only the properties of the request; values are returned as
written, date-times and geo points carry their @odata.type.
Do not set WWW-Authenticate headers when an active signed URL
authentication attempt fails. Signed URL clients cannot respond to Basic
or Bearer challenges, and advertising them may trigger unintended
authentication prompts.
Keep returning 401 Unauthorized while preserving the existing challenge
behavior for unsigned requests and disabled signed URL mechanisms.
Path was a keyword, so the descendant lookup behind delete/move/restore/purge, the scoped search and the KQL path predicate expanded into one term searcher per descendant and OOM-killed the server on large folders (#1269, #3469).
Path is now analyzed into its ancestor prefixes, like path_hierarchy in OpenSearch: ./a/b.txt becomes ., ./a, ./a/b.txt. A folder's descendants are every document carrying the folder's path as a term, so all three call sites are a single term query. Schema 4 -> 5, v4 never shipped.
The same tokenizer with tag_depth is registered as the geohash analyzer, so #3272 can add its geohash field without another schema change.
The imaging build decodes the full pixel buffer from the header-declared
dimensions before the existing MaxInputWidth/MaxInputHeight guard runs, so a
tiny crafted file whose header declares huge dimensions forces a multi-GB
allocation and can OOM the worker. Read the header with DecodeConfig and reject
oversized sources before the decode allocates, in both the imaging and vips
builds, and thread the limit through the audio cover-art and geogebra decoders
that decode a second attacker-controlled image.
The recursive tika response lists the file first, then its embedded
resources (cover art, thumbnails, the clip appended to a motion photo).
The loop applied getImage/getPhoto/getLocation/getAudio/getLivePhoto to
every part, so an mp3's embedded cover art leaked a 200x200 image facet
onto the track (and an embedded EXIF image would leak photo/location).
Read those facets from metas[0] only, like the video facet already does;
the loop now only concatenates title/content and detects the motion
photo clip.
The legacy OC-Signature path already rejects methods outside
PRE_SIGNED_URL_ALLOWED_HTTP_METHODS, the JWT path did not. A leaked
signed download url could be used for PUT, DELETE, MOVE or PROPFIND
as the signing user for the lifetime of the signature.
$expand=thumbnails was only honored by sharedByMe and sharedWithMe. The
driveItem stat, the children listing and the root children listing now
honor it as well, so a client that lists a folder learns which items have
a preview instead of guessing from the mime type.
The thumbnails are set from the resource info the listing already has, so
a later preview check that needs more than the mime type has a single
place to sit. The two share listings carry driveItems only, they keep
matching on the mime type but share the url building.
Dominik Schmidt