Invalid ETAG error with BreezeJS and IE9 - sharepoint

I am using BreezeJS with the SharePoint Adapter and get a consistent invalid etag error on the second and following POST request from client-side. Strangely, this does not happen in IE11 or the latest Google Chrome browser.
Here are some details on what is happening:
An Agenda item (id 3) is pulled from the server and has the etag value W/"4"
An update of the Agenda item is posted to the server with etag value W/"4"
Another update of the same item is posted to the server with etag value W/"4"
I get the error message: The etag value '4' specified in one of the request headers is not valid. Please make sure only one etag value is specified and is valid
The error message makes at lot of sense as we must not use the same ETAG value in two different requests. Using Google Chrome the second (and consequetive) POST request have the correctly incremented etag value. So in this case it would send W/"5" and everything would be fine.
I have noticed that the first POST request returns the new ETAG (W/"5") but it is not being applied to the second POST request. I am using the following versions:
BreezeJS: 1.4.13
Rest adapter: 0.2.3
SharePoint adapter: 0.2.3
For reference I have included the requests and responses for the three operations from Fiddler.
Get agenda item
GET http://intranet/test/_vti_bin/listdata.svc/Agenda?$filter=Id%20eq%203 HTTP/1.1
DataServiceVersion: 2.0
Accept: application/json;odata=verbose
X-Requested-With: XMLHttpRequest
Referer: http://intranet/test/SitePages/test.aspx#inmeeting/2
Accept-Language: da
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E; InfoPath.3)
Host: intranet
Connection: Keep-Alive
HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: application/json;charset=utf-8
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
SPRequestGuid: e4a8e96a-d476-41e8-8445-ecd50fe8f78e
X-SharePointHealthScore: 0
DataServiceVersion: 2.0;
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 14.0.0.7015
X-MS-InvokeApp: 1; RequireReadOnly
Date: Fri, 15 Aug 2014 10:28:59 GMT
Content-Length: 1491
{
"d" : {
"results": [
{
"__metadata": {
"uri": "http://intranet/test/_vti_bin/listdata.svc/Agenda(3)", "etag": "W/\"4\"", "type": "Microsoft.SharePoint.DataService.AgendaItem"
}, "ContentTypeID": "0x0100EF440AFE5EDF49AD87D3B9A9484C2C0300ACA340FAC0DE1D49B8514C10085EC342", "Title": "Welcome", "Meeting": {
"__deferred": {
"uri": "http://intranet/test/_vti_bin/listdata.svc/Agenda(3)/Meeting"
}
}, "MeetingId": 2, "Documents": {
"__deferred": {
"uri": "http://intranet/test/_vti_bin/listdata.svc/Agenda(3)/Documents"
}
}, "Links": {
"__deferred": {
"uri": "http://intranet/test/_vti_bin/listdata.svc/Agenda(3)/Links"
}
}, "Responsible": {
"__deferred": {
"uri": "http://intranet/test/_vti_bin/listdata.svc/Agenda(3)/Responsible"
}
}, "ResponsibleId": 1, "StartTime": "\/Date(1408622400000)\/", "EndTime": "\/Date(1408623120000)\/", "DurationInMinutes": 12, "Done": true, "Comments": null, "Sort": 0, "Id": 3, "ContentType": "Meeting Agenda", "Modified": "\/Date(1408105622000)\/", "Created": "\/Date(1408010077000)\/", "CreatedBy": {
"__deferred": {
"uri": "http://intranet/test/_vti_bin/listdata.svc/Agenda(3)/CreatedBy"
}
}, "CreatedById": 1, "ModifiedBy": {
"__deferred": {
"uri": "http://intranet/test/_vti_bin/listdata.svc/Agenda(3)/ModifiedBy"
}
}, "ModifiedById": 1, "Owshiddenversion": 4, "Version": "4.0", "Attachments": {
"__deferred": {
"uri": "http://intranet/test/_vti_bin/listdata.svc/Agenda(3)/Attachments"
}
}, "Path": "/test/Lists/Agenda"
}
]
}
}
First update of agenda item
POST http://intranet/test/_vti_bin/listdata.svc/Agenda(3) HTTP/1.1
Accept: application/json;odata=verbose
Content-Type: application/json;odata=verbose
DataServiceVersion: 2.0
X-RequestDigest: 0x5B15EE86ACA321A71DA9A2939E8FE1E2A29D3F6A60A6424C4F497DFFCD4D509836B6FB85A127CBBC947547D8AB7AE0E91CE6C72E7C359D6CF83351C024858D84,15 Aug 2014 10:26:46 -0000
X-HTTP-Method: MERGE
If-Match: W/"4"
X-Requested-With: XMLHttpRequest
Referer: http://intranet/test/SitePages/test.aspx#inmeeting/2
Accept-Language: da
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E; InfoPath.3)
Host: intranet
Content-Length: 82
Connection: Keep-Alive
Pragma: no-cache
{"Done":false,"__metadata":{"type":"Microsoft.SharePoint.DataService.AgendaItem"}}
HTTP/1.1 204 No Content
Cache-Control: no-cache
ETag: W/"5"
Server: Microsoft-IIS/7.5
SPRequestGuid: dc4896d6-91b9-4894-a169-c70889ad0747
X-SharePointHealthScore: 0
DataServiceVersion: 1.0;
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 14.0.0.7015
X-MS-InvokeApp: 1; RequireReadOnly
Date: Fri, 15 Aug 2014 10:29:02 GMT
Second update of Agenda item
POST http://intranet/test/_vti_bin/listdata.svc/Agenda(3) HTTP/1.1
Accept: application/json;odata=verbose
Content-Type: application/json;odata=verbose
DataServiceVersion: 2.0
X-RequestDigest: 0x5B15EE86ACA321A71DA9A2939E8FE1E2A29D3F6A60A6424C4F497DFFCD4D509836B6FB85A127CBBC947547D8AB7AE0E91CE6C72E7C359D6CF83351C024858D84,15 Aug 2014 10:26:46 -0000
X-HTTP-Method: MERGE
If-Match: W/"4"
X-Requested-With: XMLHttpRequest
Referer: http://intranet/test/SitePages/test.aspx#inmeeting/2
Accept-Language: da
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E; InfoPath.3)
Host: intranet
Content-Length: 81
Connection: Keep-Alive
Pragma: no-cache
{"Done":true,"__metadata":{"type":"Microsoft.SharePoint.DataService.AgendaItem"}}
HTTP/1.1 412 Precondition Failed
Cache-Control: private
Content-Type: application/json
Server: Microsoft-IIS/7.5
SPRequestGuid: 965fbf16-8911-426b-9a90-8b21b4a78008
X-SharePointHealthScore: 0
DataServiceVersion: 1.0;
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 14.0.0.7015
X-MS-InvokeApp: 1; RequireReadOnly
Date: Fri, 15 Aug 2014 10:29:02 GMT
Content-Length: 214
{
"error": {
"code": "", "message": {
"lang": "en-US", "value": "The etag value '4' specified in one of the request headers is not valid. Please make sure only one etag value is specified and is valid."
}
}
}
UPDATE 1
I have done some debugging and started at the _processSavedEntity method of the SPAdapter. In Chrome it receives the new ETAG value from the response, in IE9 it gets null. Tracing this back I ended in breeze.debug.js (1.4.13) at line 15156 where the response gets into the system. Calling the getAllResponseHeaders() methods on the jqXHR returns an empty string in IE9, while Fiddler shows the headers present (same as above). So, that's a bit of a mystery. BTW. I'm using jQuery 1.9.1.

The problem is that IE9 and previous, when receiving a response code 204 No Content, throws away all the response headers.
It is discussed here jQuery.ajax with POST or PUT has no response headers for IE8 and IE9
If there are no concurrency problems, the driver could sniff IE9 and previous and issue a HEAD (I don't know if SharePoint supports it) or a GET for the same entity.
But both hacks give concurrency problems. Which one is worse depends on the context.
In any case, the whole purpose of having ETags for optimistic concurrency is defeated.
I am afraid that there is no way to fully support optimistic concurrency for OData in IE9 and previous.

Related

Node.js express server with compression not work

From lighthouse chrome test page:
URL Transfer Size Potential Savings
/three.module.min.js 630.3 KiB 477.3 KiB
I minify but performance still need compression.
...
function shouldCompress (req, res) {
if (req.headers['x-no-compression']) {
// don't compress responses with this request header
return false
}
// fallback to standard filter function
return compression.filter(req, res)
}
hostingHTTP.use(compression({ filter: shouldCompress }))
...
My request :
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,ru;q=0.8
Cache-Control: no-cache
Connection: keep-alive
Host: maximumroulette.com
Pragma: no-cache
Referer: https://maximumroulette.com/apps/magic/public/module.html
sec-ch-ua: "Not_A Brand";v="99", "Google Chrome";v="109", "Chromium";v="109"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Sec-Fetch-Dest: script
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36
My response:
Accept-Ranges: bytes
Cache-Control: public, max-age=0
Connection: keep-alive
Content-Length: 394590
Content-Type: application/javascript; charset=UTF-8
Date: Mon, 13 Feb 2023 20:39:00 GMT
ETag: W/"6055e-1864c7208a7"
Keep-Alive: timeout=5
Last-Modified: Mon, 13 Feb 2023 20:23:07 GMT
X-Powered-By: Express
Did i need some action onclietn part for decopression ?
If i setup on server res.set('Content-Encoding', 'deflate'); // gzip, deflate, br a get error on chrome:
net::ERR_CONTENT_DECODING_FAILED 200 (OK)
Any suggestion ?

Why is the Azure Logic app HTTP module modifying the response payload?

I'm trying to fetch data from a ticketing system with logic app, using the built-in HTTP module.
When testing with postman, I get the following response:
GET: https://ticketsystem/api/ticket/{{number}}
{
"tickets": [
{
"links": {
"data1": {
"id": 4
},
"data2": {
"id": 3
},
"data3": {
"id": 969
}
...
},
"data1Id": 4,
"data2Id": 3,
"data3Id": 969,
"att1": 1,
"att1": 2,
"att1": 3,
"att1": 4
....
}
]}
But, when trying through the HTTP logic app module, this is the response:
{
"data1Id": 4,
"data2Id": 3,
"data3Id": 969,
"att1": 1,
"att1": 2,
"att1": 3,
"att1": 4
...
}
Everything else is the same, I have even tried in a new logic app and a totally different azure account. It is still the same.
I've looked through the http header response, and there are some differences.
Postman:
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/vnd.api+json; charset=utf-8
Content-Encoding: gzip
Expires: -1
Vary: Accept-Encoding
Server: Microsoft-IIS/10.0
X-PS-ActionTime: 00:00:00.0022451
X-Frame-Options: deny
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Date: Wed, 16 Jun 2021 09:41:50 GMT
Content-Length: 819
Azure HTTP:
"Pragma": "no-cache",
"Vary": "Accept-Encoding",
"X-PS-ActionTime": "00:00:00.0022021",
"X-Frame-Options": "deny",
"X-XSS-Protection": "1; mode=block",
"Strict-Transport-Security": "max-age=31536000; includeSubDomains; preload",
"Cache-Control": "no-cache",
"Date": "Wed, 16 Jun 2021 09:43:27 GMT",
"Server": "Microsoft-IIS/10.0",
"Content-Type": "application/json; charset=utf-8",
"Expires": "-1",
"Content-Length": "1733"
It looks like the "Content-Encoding: gzip" is missing from logic app, but I do not know why this is affecting the overall response structure. Also how to fix this issue.
I have tried to enable "Allow chunking", without any luck.
I understand that I might create an Azure Function to go around this, but I'm trying to avoid that for now.
Any advice?
EDIT
I tested with powershell Invoke-WebRequest, and I see that this is behaving the same as the Logic app HTTP action.
From powershell, the header is also the same (missing Content-Encoding: gzip) and the "Content-Type" = "application/json; charset=utf-8"
But, when testing with python (3.9) with the request module, then it's spitting out the same data as postman.
Content-Type: application/vnd.api+json; charset=utf-8
Content-Encoding: gzip
I am really trying to understand the difference here on the header level, as this is the only difference between the responses, and also what application/vnd.api+json and Content-Encoding: gzip does here.
Did you check this :
https://learn.microsoft.com/en-us/azure/connectors/connectors-native-http#omitted-http-headers
I see a feedback for this too: https://feedback.azure.com/forums/287593-logic-apps/suggestions/42578674-enable-support-for-content-type-header-in-http-get
I've sovled it.
I simply put this as a header on the HTTP Action:
"Accept": "application/vnd.api+json; charset=utf-8"
And the response message was the same as in Postman.
This still does not answer why it is behaving differently, since none of the request headers had this value in all of the metodes I tried.

Python POST request to retrieve base64 encode File

Im trying to POST request using Python to retreive a specific File. Since the URL is behind a server with authorized access theres no use posting it here
However the form data contains a field called base64 and lengthy which I cant figure out if its a form data value or base64 encoding of post request
Here are browser parameters
General:
Request URL: http://exampleapi.com/api/Document/Export
Request Method: POST
Status Code: 200 OK
Remote Address: XX.XXX.XXX.XX:XX
Referrer Policy: no-referrer-when-downgrade
Response Headers:
Access-Control-Allow-Origin: http://example.com
Cache-Control: no-cache
Content-Disposition: attachment; filename=location-downloads.xlsx
Content-Length: 7148
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Date: Tue, 23 Jul 2019 21:00:18 GMT
Expires: -1
Pragma: no-cache
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Request Headers :
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cache-Control: max-age=0
Connection: keep-alive
Content-Length: 10162
Content-Type: application/x-www-form-urlencoded
Cookie: abcConnection=!UA7tkC3iZCmVNGRUyRpDWARVBWk/lY6SZvgxLlaygsQKk+vuwA1NxvhwE9ph4i+3NZlKeepIfuHhUvyQjl68fhhrT9ueqMx/3mBKUDcT
DNT: 1
Host: exampleapi.com
Origin: http://example.com
Referer: http://example.com/
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36
Form Data:
fileName: location-downloads.xlsx
contentType: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
base64: UEsDBAoAAAAAAAh4904AAAAAAAAAAAAAAAAJAAAAZG9jUHJvcHMvUEsDBAoAAAAIAAh490(shortened for simplicity)
Here is what I tried
url='http://example.com'
urllib3.disable_warnings()
headers = {
"Content-Type": "application/x-www-form-urlencoded",
"User-Agent": "Mozilla/5.0",
}
with requests.session() as s:
r=s.get(url,headers={"User-Agent":"Mozilla/5.0"},verify=False)
data=r.content
soup=BeautifulSoup(data,'html.parser')
form_data = {
"fileName":"location-downloads.xlsx",
"contentType":"application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
}
r2=s.post('http://exampleapi.com/api/Document/Export',data=json.dumps(form_data,ensure_ascii=True).encode('utf-8'),headers=headers,verify=False)
print(r2.status_code)
Any idea how i should proceed. My status code also shows 500 for the post here

Access to a web page via a robot

I need to occasionally access an HTML page to update a database. This page is easily accessible via a web browser, but when I try to access it via a node.js application it doesn't work (the website detect that the request is made by a robot). However,
The robot request contains the same headers (including the
user-agent) that the web browser request.
The robot request doesn't contains referer header or cookie header, but the browser request either.
The IP of the robot is the same that the IP that I use
to browse the website.
In my eyes the robot request and the browser request are strictly identical. Nevertheless they are processed differently.
I'm running out of ideas... Maybe the request contains metadata like "this request was sent by node.js" but it would be really weird.
EDIT, here is a code sample :
// callback (error, responseContent)
function getPage (callback){
let options = {
protocol : 'https:',
hostname : 'xxx.yyy.fr',
port : 443,
path : '/abc/def',
agent : false,
headers : {
'Accept' : 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
'Accept-Encoding' : 'gzip, deflate, br',
'Accept-Language' : 'fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3',
'Cache-Control' : 'no-cache',
'Connection' : 'keep-alive',
'DNT' : '1',
'Host' : 'ooshop.carrefour.fr',
'Pragma' : 'no-cache',
'Upgrade-Insecure-Requests' : '1',
'User-Agent' : 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0'
}
};
https.get (options, function (res){
if (res.statusCode !== 200){
res.resume ();
callback ('Error : res code != 200, res code = ' + res.statusCode);
return;
}
res.setEncoding ('utf-8');
let content = '';
res.on ('data', chunk => content += chunk);
res.on ('end', () => callback (null, content));
}).on ('error', e => callback (e));
}
EDIT : here is a comparison of the requests/responses :
Mozilla Firefox
request headers :
GET /3274080001005/eau-de-source-cristaline HTTP/1.1
Host: ooshop.carrefour.fr
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Pragma: no-cache
Cache-Control: no-cache
response headers :
HTTP/2.0 200 OK
date: Wed, 11 Jul 2018 21:25:25 GMT
server: Unknown
content-type: text/html; charset=UTF-8
age: 0
x-varnish-cache: MISS
accept-ranges: bytes
set-cookie: visid_incap_1213048=G8a0mWzmQYi0GKuT2Ht7YeQ9QVsAAAAAQkIPAAAAAADvVZnsZHK18dQQxHakBprg; expires=Thu, 11 Jul 2019 11:17:56 GMT; path=/; Domain=.carrefour.fr
incap_ses_466_1213048=/2NKHS4HXU0T7FpkwpJ3BsV1RlsAAAAAAY3wbUkXacAceu2NkgUrhw==; path=/; Domain=.carrefour.fr
x-iinfo: 7-11020186-11020187 NNNN CT(1 2 0) RT(1531344324722 0) q(0 0 0 0) r(4 4) U12
x-cdn: Incapsula
content-encoding: gzip
X-Firefox-Spdy: h2
response content : expected HTML page
Node.js robot
request headers :
Accept : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding : gzip, deflate, br
Accept-Language : fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Cache-Control : no-cache
Connection : keep-alive
DNT : 1
Host : ooshop.carrefour.fr
Pragma : no-cache
Upgrade-Insecure-Requests : 1
User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
response headers :
content-type : text/html
connection : close, close
cache-control : no-cache
content-length : 210
x-iinfo : 1-17862634-0 0NNN RT(1531344295049 65) q(0 -1 -1 0) r(0 -1) B10(4,314,0) U19
set-cookie : incap_ses_466_1213048=j34jMBWkPFYT7FpkwpJ3Bqd1RlsAAAAAVBfoZBShAvoun/M8UFxPPA==; path=/; Domain=.carrefour.fr
response content :
<html>
<head>
<META NAME="robots" CONTENT="noindex,nofollow">
<script src="/_Incapsula_Resource?SWJIYLWA=5074a744e2e3d891814e9a2dace20bd4,719d34d31c8e3a6e6fffd425f7e032f3">
</script>
<body>
</body></html>

When trying to expand the fields of a sharepoint list item returns http response 401

I am using the beta microsoft graph request to expand the fields of a list item. Like this:
GET https://graph.microsoft.com/beta/sites/{site-id}/lists/{list-id}/items/{item-id}?expand=fields
According to my permissions I comply the prereqs with Sites.ReadWrite.All. But still I receive 401 with the following response body:
{
"error": {
"code": "unauthenticated",
"message": "Access denied. You are not authorized to perform this operation or open this resource.",
"innerError": {
"request-id": "xxx-xx-xxx-xx-xxxxxxxxx",
"date": "2017-05-30T08:46:28"
}
}
}
Edit:
Even without the expand the response is now 401. So requesting a single item also gives a 401. The used http request and headers are:
GET https://graph.microsoft.com/beta/sites/xxxxxxxxxxx.sharepoint.com,2f72ee36-b572-4919-bc5f-66a41f8fd128,f01a93c4-ce7a-4b37-b214-d868d39204ef/lists/fa190d14-7ab0-42a3-860d-d1cde4d93ccf/items/853adfa7-d114-425c-998f-54a58496bfbc HTTP/1.1
Host: graph.microsoft.com
Connection: keep-alive
Origin: https://developer.microsoft.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Authorization: Bearer yyyyyyyyyyyyyyyyyyyyyyyyy
Referer: https://developer.microsoft.com/en-us/graph/graph-explorer
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4
The response:
HTTP/1.1 401 Unauthorized
Cache-Control: private
Content-Type: application/json
request-id: xxx-xx-xxx-xx-xxxxxxxxx
client-request-id: xxx-xx-xxx-xx-xxxxxxxxx
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"West Europe","Slice":"SliceA","ScaleUnit":"002","Host":"AGSFE_IN_1","ADSiteName":"AMS"}}
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: ETag, Location, Preference-Applied, Content-Range, request-id, client-request-id
Duration: 320.1951
Date: Wed, 31 May 2017 08:43:44 GMT
Content-Length: 298
{
"error": {
"code": "unauthenticated",
"message": "Toegang geweigerd. U bent niet gemachtigd om deze bewerking uit te voeren of deze bron te openen.",
"innerError": {
"request-id": "xxx-xx-xxx-xx-xxxxxxxxx",
"date": "2017-05-31T08:43:44"
}
}
}

Resources