$batch failed - Error: Expected 'OData-Version' header with value '4.0' but received value 'null' in response

[mgerzabek]

Hi @27pchrisl,

Not sure if this is the right repo to report…

Now when executing the $batch I get the error

2024-01-14 17:16:06.903800 $batch failed - Error: Expected 'OData-Version' header with value '4.0' but received value 'null' in response for http://localhost/odata/$batch
    at _Requestor.doCheckVersionHeader (http://localhost:8080/resources/sap/ui/model/odata/v4/lib/_Requestor.js:761:9)
    at Object.<anonymous> (http://localhost:8080/resources/sap/ui/model/odata/v4/lib/_Requestor.js:1999:12)
    at Object.eval (http://localhost:8080/resources/sap/ui/thirdparty/jquery-compat.js?eval:725:30)
    at fire (http://localhost:8080/resources/sap/ui/thirdparty/jquery.js?eval:3500:31)
    at Object.fireWith [as resolveWith] (http://localhost:8080/resources/sap/ui/thirdparty/jquery.js?eval:3630:7)
    at done (http://localhost:8080/resources/sap/ui/thirdparty/jquery.js?eval:9911:14)
    at XMLHttpRequest.eval (http://localhost:8080/resources/sap/ui/thirdparty/jquery.js?eval:10172:9) sap.ui.model.odata.v4.ODataModel

But this is strange for several reasons. Let's go slow.

It looks like openui5 is doing the $batch twice.

The first is done in the form

OPTIONS /odata/$batch HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
Access-Control-Request-Headers: content-type,mime-version,odata-maxversion,odata-version,x-csrf-token
Access-Control-Request-Method: POST
Cache-Control: no-cache
Connection: keep-alive
Host: localhost
Origin: http://localhost:8080
Pragma: no-cache
Referer: http://localhost:8080/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6 Mobile/15E148 Safari/604.1

which get's as response

HTTP/1.0 204 No Content
Date: Sun, 14 Jan 2024 16:16:06 GMT
Server: Apache/2.4.58 (Unix) PHP/8.2.14
X-Powered-By: PHP/8.2.14
Cache-Control: no-cache, private
Access-Control-Allow-Origin: *
Vary: Access-Control-Request-Method,Access-Control-Request-Headers
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: content-type,mime-version,odata-maxversion,odata-version,x-csrf-token
Access-Control-Max-Age: 0
Connection: close

There is no OData-Version present.

But the second $batch

POST /odata/$batch HTTP/1.1
Accept: multipart/mixed
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 345
Content-Type: multipart/mixed; boundary=batch_id-1705248966761-20
Host: localhost
MIME-Version: 1.0
OData-MaxVersion: 4.0
OData-Version: 4.0
Origin: http://localhost:8080
Pragma: no-cache
Referer: http://localhost:8080/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6 Mobile/15E148 Safari/604.1
X-CSRF-Token: Fetch

with the payload from my previous issue which get's a full response with the headers

HTTP/1.1 200 OK
Date: Sun, 14 Jan 2024 16:16:06 GMT
Server: Apache/2.4.58 (Unix) PHP/8.2.14
X-Powered-By: PHP/8.2.14
Cache-Control: no-cache, private
odata-version: 4.0
Access-Control-Allow-Origin: *
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: multipart/mixed;boundary=3ea5cada-7885-4af4-bdf0-fa7036e5b52b

obviously contains the OData-Version header stated in lower case letters.

Then after the error stated in the entry of this issue a second error is shown

2024-01-14 17:16:06.904500 Failed to get contexts for http://localhost/odata/Times with start index 0 and length 500 - Error: HTTP request was not processed because $batch failed

I'm really confused and don't exactly know where to look.
Can it be that the case insensitive nature of odata-version is a problem?
In some related case it looks like the header Access-Control-Expose-Headers which should contain the OData-Version string to allow the client to acces this header helped. Can this be an issue?

Any help welcomed.

[27pchrisl]

Yep I think that's the issue. Adding OData-Version to the exposed_headers array in config/cors.php should do what is being suggested.

[mgerzabek]

@27pchrisl,
You are unbelievable! The prototyp is live on laravel.
Thank you very much!!!

[mgerzabek]

Forgot to close…