cTag format is different in response headers when fetching the file contents

Question

Ivan Maria 86

When I use the following API

GET /drives/{drive-id}/items/{item-id}

I get the following ctag value in the response body

"c:{21087D96-34CA-416F-8613-F8ED59C6DB34},5"

The above ctag works well with If-Match header for subsequent requests.

However, when I use the following API

GET /drives/{drive-id}/items/{item-id}/content

I get the following ctag value in response header.

{21087D96-34CA-416F-8613-F8ED59C6DB34},6,5

As the format of above ctag is different, it always fail for If-Match header in subsequent requests.

What is the recommended way of handling the ctag value correctly?

Deva-MSFT 2,276 Reputation points Microsoft Employee Moderator

2021-06-20T09:08:58.567+00:00

What error you're getting? Share the graph response along with requestid, timestamp
Arie 0 Reputation points

2026-01-20T11:25:31.2766667+00:00
I'm getting the same issue.

This request behaves as expected/documented:

GET /drives/{drive-id}/items/{item-id}/content If-None-Match: "c:{12345678-ABCD-12AB-1234-CDEF1234ABCD},5"

If the ctag matches, returns HTTP 304 Not Modified, otherwise HTTP 200 OK. The API seems to correctly interpret the "c:" prefix correctly. The returned ETag header doesn't contain this prefix.

However, if using If-Match header, the API does not behave as expected:

GET /drives/{drive-id}/items/{item-id}/content If-Match: "c:{12345678-ABCD-12AB-1234-CDEF1234ABCD},5"

The response is always a HTTP 412 Precondition Failed. It should be HTTP 200 OK when the ctag matches. This is the behavior I need to be sure I'm downloading the expected file version.

If I strip the "c:" prefix, then the second request does behave as expected. However, I'd rather not rely on this since it isn't documented.

I can share request IDs if anybody is still monitoring this post

Your answer

Deva-MSFT 2,276 Reputation points Microsoft Employee Moderator

2021-06-20T09:08:58.567+00:00

What error you're getting? Share the graph response along with requestid, timestamp
Arie 0 Reputation points

2026-01-20T11:25:31.2766667+00:00

I'm getting the same issue.

This request behaves as expected/documented:

GET /drives/{drive-id}/items/{item-id}/content If-None-Match: "c:{12345678-ABCD-12AB-1234-CDEF1234ABCD},5"

If the ctag matches, returns HTTP 304 Not Modified, otherwise HTTP 200 OK. The API seems to correctly interpret the "c:" prefix correctly. The returned ETag header doesn't contain this prefix.

However, if using If-Match header, the API does not behave as expected:

GET /drives/{drive-id}/items/{item-id}/content If-Match: "c:{12345678-ABCD-12AB-1234-CDEF1234ABCD},5"

The response is always a HTTP 412 Precondition Failed. It should be HTTP 200 OK when the ctag matches. This is the behavior I need to be sure I'm downloading the expected file version.

If I strip the "c:" prefix, then the second request does behave as expected. However, I'd rather not rely on this since it isn't documented.

I can share request IDs if anybody is still monitoring this post