`DataLakeFileClient.set_file_expiry()` with `expiry_options="NeverExpire"` Fails Due to Incorrect HTTP Header Format

[prejs]

• Package Name: azure-storage-file-datalake
• Package Version: 12.17.0
• Operating System: macOS 15.1 (24B83)
• Python Version: 3.12.7

Describe the bug
DataLakeFileClient.set_file_expiry() for expiry_options="NeverExpire" fails with:

azure.core.exceptions.HttpResponseError: Operation returned an invalid status 'The value for one of the HTTP headers is not in the correct format.'

To Reproduce
Steps to reproduce the behavior:

1. Create DataLakeFileClient instance
2. Invoke set_file_expiry(expiry_options="NeverExpire")

account_url = f"https://{account_name}.dfs.core.windows.net"
file_system_name = ""
file_path = ""
token_credential = DefaultAzureCredential()

file_client = DataLakeFileClient(
    account_url,
    file_system_name,
    file_path,
    token_credential)

file_client.set_file_expiry(
    expiry_options="NeverExpire",
    expires_on=None,
)

Logs:

Request URL: 'https://{account_name}.blob.core.windows.net/{file_system_name}/{file_path}?comp=expiry'
Request method: 'PUT'
Request headers:
    'x-ms-version': '2024-11-04'
    'x-ms-expiry-option': 'NeverExpire'
    'x-ms-expiry-time': 'None'
    'Accept': 'application/json'
    'User-Agent': 'azsdk-python-storage-dfs/12.17.0 Python/3.12.7 (macOS-15.1-arm64-arm-64bit)'
    'x-ms-date': 'Wed, 13 Nov 2024 17:02:57 GMT'
    'x-ms-client-request-id': '*****'
    'Authorization': '*****'
Request body:
None
Response status: 400
Response headers:
    'Content-Length': '255'
    'Content-Type': 'application/xml'
    'Server': 'Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0'
    'x-ms-error-code': 'InvalidHeaderValue'
    'x-ms-request-id': '*****'
    'x-ms-version': '2024-11-04'
    'x-ms-client-request-id': '*****'
    'Date': 'Wed, 13 Nov 2024 17:02:57 GMT'
Response content:
b'\xef\xbb\xbf<?xml version="1.0" encoding="utf-8"?>\n<Error><Code>InvalidHeaderValue</Code><Message>The value for one of the HTTP headers is not in the correct format.\nRequestId:35344836-f01e-0005-28ed-3546a9000000\nTime:2024-11-13T17:02:58.1992521Z</Message></Error>'

Expected behavior
File property expiry_time is reset.

Additional context

• I wasn't able to find a expires_on value that satisfies the endpoint.

• I was able to modify headers to satisfy the endpoint, so I believe the x-ms-expiry-time header is redundant.

    ...
   
    def fix_headers(request):
        request.http_request.headers.pop('x-ms-expiry-time', None)
    
    file_client.set_file_expiry(
        expiry_options="NeverExpire",
        raw_request_hook=fix_headers,
    )

  Logs:

  Request URL: 'https://{account_name}.blob.core.windows.net/{file_system_name}/{file_path}?comp=expiry'
  Request method: 'PUT'
  Request headers:
      'x-ms-version': '2024-11-04'
      'x-ms-expiry-option': 'NeverExpire'
      'Accept': 'application/json'
      'User-Agent': 'azsdk-python-storage-dfs/12.17.0 Python/3.12.7 (macOS-15.1-arm64-arm-64bit)'
      'x-ms-date': 'Wed, 13 Nov 2024 17:01:30 GMT'
      'x-ms-client-request-id': '*****'
      'Authorization': '*****'
  Request body:
  None
  Response status: 200
  Response headers:
      'Last-Modified': 'Tue, 12 Nov 2024 09:46:21 GMT'
      'ETag': '"0x8DD02FEDD216B20"'
      'Server': 'Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0'
      'x-ms-request-id': '*****'
      'x-ms-version': '2024-11-04'
      'x-ms-client-request-id': '*****'
      'Date': 'Wed, 13 Nov 2024 17:01:29 GMT'
      'Content-Length': '0'
  Response content:
  b''
  

[github-actions]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @jalauzon-msft @vincenttran-msft.

[jalauzon-msft]

Hi @prejs, thanks for reporting the issue and for your investigation! This does in fact seem like a bug. We will work on getting it fixed for our next release however that may not be until next year (we have one coming this week, but the fix won't make it) so for now, hopefully the workaround you provided can work for you. Thanks!

[prejs]

Hi @jalauzon-msft, thanks for prompt response and confirmation. The workaround is indeed sufficient, so a fix needs no rush.
However, I treated the bug as "good first issue" and proposed a fix... which failed badly on mismatched test recordings. I guess it is as far as I can get. I will wait patiently for next year.