Genesys Cloud - Developer Community!

Hi Jerome.

Thanks for your insights.

I started out down the track of catching the exception, pulling out the downloadUrl, and then fetching the data from that URL. But then I struck a network error which at the time I assumed was CORS-related, but thinking more about it now, we had some Zscaler issues at the time which would almost certainly have impacted my testing, so I probably need to give this another shot. Anyway I ended up just reducing the pageSize to 100, and now it seems to work OK (but probably takes 5 times as long to retrieve all the data).

I'll do some more testing with this when I get time, and raise a support case based on my findings. Thanks for your help!

Nick.

I've retested the AuditApi.getAuditsQueryTransactionIdResults() just now, under the following conditions:

• Specifying a large pageSize: 500
• Specifying opts: { allowRedirect: true }
• The size of the audit events that would be returned exceeds the threshold (1MB?).
• My code then catches the exception, extracts the downloadUrl, and uses fetch() to retrieve the data.

It turns out that this is blocked due to CORS restrictions:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api-downloads.mypurecloud.com.au/audit-query-results/52759a62-9bf1-4f17-ab7a-0ea3deeda3bc/3e58c89e-e0e9-4126-afc7-183b38b1b31c-500?response-content-disposition=attachment%3Bfilename%3D%22Audit_Results%22&Expires=1780026090&Signature=...&Key-Pair-Id=K21FSGH5HMHI4N. (Reason: CORS header 'Access-Control-Allow-Origin' missing). Status code: 200.

Jerome, you mentioned that if the Location header had been returned in the initial response, the SDK running within a browser environment would have followed the redirect automatically (and couldn't be overridden in the code)? If so, that could only work if the second request (to api-downloads.mypurecloud.com.au) included CORS headers to allow access from anywhere? Do you think that is a reasonable thing to request (e.g. via support case)? Or do you think I would be wasting my time raising this?

Thanks,

Nick.

Hi Jerome.

Thanks for your insights.

I started out down the track of catching the exception, pulling out the downloadUrl, and then fetching the data from that URL. But then I struck a network error which at the time I assumed was CORS-related, but thinking more about it now, we had some Zscaler issues at the time which would almost certainly have impacted my testing, so I probably need to give this another shot. Anyway I ended up just reducing the pageSize to 100, and now it seems to work OK (but probably takes 5 times as long to retrieve all the data).

I'll do some more testing with this when I get time, and raise a support case based on my findings. Thanks for your help!

Nick.

Hello,

Yes, that is worth reporting (and raising a ticket).

I mean mentioning that you can't download the file from a browser because of the lack of Access-Control-Allow-Origin on last endpoint. And at the same time mentioning that having the Location header present on first redirect would also makes sense and be useful.

Regards,

I've retested the AuditApi.getAuditsQueryTransactionIdResults() just now, under the following conditions:

• Specifying a large pageSize: 500
• Specifying opts: { allowRedirect: true }
• The size of the audit events that would be returned exceeds the threshold (1MB?).
• My code then catches the exception, extracts the downloadUrl, and uses fetch() to retrieve the data.

It turns out that this is blocked due to CORS restrictions:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api-downloads.mypurecloud.com.au/audit-query-results/52759a62-9bf1-4f17-ab7a-0ea3deeda3bc/3e58c89e-e0e9-4126-afc7-183b38b1b31c-500?response-content-disposition=attachment%3Bfilename%3D%22Audit_Results%22&Expires=1780026090&Signature=...&Key-Pair-Id=K21FSGH5HMHI4N. (Reason: CORS header 'Access-Control-Allow-Origin' missing). Status code: 200.

Jerome, you mentioned that if the Location header had been returned in the initial response, the SDK running within a browser environment would have followed the redirect automatically (and couldn't be overridden in the code)? If so, that could only work if the second request (to api-downloads.mypurecloud.com.au) included CORS headers to allow access from anywhere? Do you think that is a reasonable thing to request (e.g. via support case)? Or do you think I would be wasting my time raising this?

Thanks,

Nick.

Hi Jerome.

Thanks for your insights.

I started out down the track of catching the exception, pulling out the downloadUrl, and then fetching the data from that URL. But then I struck a network error which at the time I assumed was CORS-related, but thinking more about it now, we had some Zscaler issues at the time which would almost certainly have impacted my testing, so I probably need to give this another shot. Anyway I ended up just reducing the pageSize to 100, and now it seems to work OK (but probably takes 5 times as long to retrieve all the data).

I'll do some more testing with this when I get time, and raise a support case based on my findings. Thanks for your help!

Nick.

Hi Jerome.

The Genesys development team have added the CORS headers, but aren't prepared to add the Location header.

I tried to convince them that adding the Location header wasn't risky:

Can I please ask for clarification about why they think adding the Location header is risky? Because if they are worried about breaking existing code, then let us consider what the existing code would look like... i.e. Based on the old behaviour, existing code would follow one of these patterns:

a) Existing code may not include allowRedirect=true, in which case they are not impacted by what we are discussing;

b) Existing code may include allowRedirect=true, then catch an exception, and extract downloadUrl from the exception object, and fetch it (via a CORS proxy or similar to work around the missing CORS headers).

In scenario (b), it is expected that the addition of a Location header would result in the following behaviour: The SDK would (hopefully) process the 302 response, extract the Location header, and then fetch the resulting URL. The response that is returned would then be passed back as the result of the getAuditsQueryTransactionIdResults function. In other words from the program's perspective, it doesn't even know that there was a redirection - all it knows is it called the SDK function and got a result and no exception was thrown. In other words the program would follow exactly the same path as if the response had been small enough to be returned without the redirection.

(On the other hand, if the SDK doesn't handle the Location header in the way I've described, then the SDK will continue to throw the exception exactly the same as it does today, and the program will catch it and do exactly what it does today.)

In other words, I'd like to understand under what scenario could adding the Location header result in anything breaking?

But this is their response:

Adding the Location header is not a simple fix - the API layer currently passes through the response from the downstream service as-is. 
Constructing a proper Location header would require new logic to extract the signed URL (with query parameters) from the response body and format it as a header value. This changes the API response contract.
 
Additionally, the team considers that existing customers may have built solutions around the current behavior (302 with downloadUrl in body). 
Any change to how the 302 response is structured could affect those solutions in unpredictable ways.
 
The Location header enhancement is outside the scope of a bug fix and would need to go through the product enhancement process (via the Product Ideas Lab)

So it looks like a dead-end. Are there any strings you could pull on your side?

Thanks,

Hello,

Yes, that is worth reporting (and raising a ticket).

I mean mentioning that you can't download the file from a browser because of the lack of Access-Control-Allow-Origin on last endpoint. And at the same time mentioning that having the Location header present on first redirect would also makes sense and be useful.

Regards,

I've retested the AuditApi.getAuditsQueryTransactionIdResults() just now, under the following conditions:

• Specifying a large pageSize: 500
• Specifying opts: { allowRedirect: true }
• The size of the audit events that would be returned exceeds the threshold (1MB?).
• My code then catches the exception, extracts the downloadUrl, and uses fetch() to retrieve the data.

It turns out that this is blocked due to CORS restrictions:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api-downloads.mypurecloud.com.au/audit-query-results/52759a62-9bf1-4f17-ab7a-0ea3deeda3bc/3e58c89e-e0e9-4126-afc7-183b38b1b31c-500?response-content-disposition=attachment%3Bfilename%3D%22Audit_Results%22&Expires=1780026090&Signature=...&Key-Pair-Id=K21FSGH5HMHI4N. (Reason: CORS header 'Access-Control-Allow-Origin' missing). Status code: 200.

Jerome, you mentioned that if the Location header had been returned in the initial response, the SDK running within a browser environment would have followed the redirect automatically (and couldn't be overridden in the code)? If so, that could only work if the second request (to api-downloads.mypurecloud.com.au) included CORS headers to allow access from anywhere? Do you think that is a reasonable thing to request (e.g. via support case)? Or do you think I would be wasting my time raising this?

Thanks,

Nick.

Hi Jerome.

Thanks for your insights.

I started out down the track of catching the exception, pulling out the downloadUrl, and then fetching the data from that URL. But then I struck a network error which at the time I assumed was CORS-related, but thinking more about it now, we had some Zscaler issues at the time which would almost certainly have impacted my testing, so I probably need to give this another shot. Anyway I ended up just reducing the pageSize to 100, and now it seems to work OK (but probably takes 5 times as long to retrieve all the data).

I'll do some more testing with this when I get time, and raise a support case based on my findings. Thanks for your help!

Nick.

Hello Nick,

Unfortunately, I don't have that much influence.

But could you please tell me what HTTP Responses you are receiving in this scenario? I haven't been able to reproduce the 302. I have more than 500 audit entities in my test environment, but the response size is under 500 KB and does not seem to be enough to trigger the redirect scenario.

I'd like to understand if the 302 without the Location header is the first response you receive when calling getAuditsQueryTransactionIdResults (or if there is an intermediate redirect).

And more importantly, what the downloadUrl, that you receive in the 302 Response body, is. I mean if it is a Genesys Cloud url - like https://api.mypurecloud.com/something or even https://api.mypurecloud.com/api/v2/downloads/{downloadId} - or if it is a url that points to an S3.

I'd like to see if there is something I can do differently in the SDK to cope with this endpoint/scenario. It won't happen shortly (I mean not in the next days) but I'd like to check what/if I can do about it when I can.

Regards,

Hi Jerome.

The Genesys development team have added the CORS headers, but aren't prepared to add the Location header.

I tried to convince them that adding the Location header wasn't risky:

Can I please ask for clarification about why they think adding the Location header is risky? Because if they are worried about breaking existing code, then let us consider what the existing code would look like... i.e. Based on the old behaviour, existing code would follow one of these patterns:

a) Existing code may not include allowRedirect=true, in which case they are not impacted by what we are discussing;

b) Existing code may include allowRedirect=true, then catch an exception, and extract downloadUrl from the exception object, and fetch it (via a CORS proxy or similar to work around the missing CORS headers).

In scenario (b), it is expected that the addition of a Location header would result in the following behaviour: The SDK would (hopefully) process the 302 response, extract the Location header, and then fetch the resulting URL. The response that is returned would then be passed back as the result of the getAuditsQueryTransactionIdResults function. In other words from the program's perspective, it doesn't even know that there was a redirection - all it knows is it called the SDK function and got a result and no exception was thrown. In other words the program would follow exactly the same path as if the response had been small enough to be returned without the redirection.

(On the other hand, if the SDK doesn't handle the Location header in the way I've described, then the SDK will continue to throw the exception exactly the same as it does today, and the program will catch it and do exactly what it does today.)

In other words, I'd like to understand under what scenario could adding the Location header result in anything breaking?

But this is their response:

Adding the Location header is not a simple fix - the API layer currently passes through the response from the downstream service as-is. 
Constructing a proper Location header would require new logic to extract the signed URL (with query parameters) from the response body and format it as a header value. This changes the API response contract.
 
Additionally, the team considers that existing customers may have built solutions around the current behavior (302 with downloadUrl in body). 
Any change to how the 302 response is structured could affect those solutions in unpredictable ways.
 
The Location header enhancement is outside the scope of a bug fix and would need to go through the product enhancement process (via the Product Ideas Lab)

So it looks like a dead-end. Are there any strings you could pull on your side?

Thanks,

Hello,

Yes, that is worth reporting (and raising a ticket).

I mean mentioning that you can't download the file from a browser because of the lack of Access-Control-Allow-Origin on last endpoint. And at the same time mentioning that having the Location header present on first redirect would also makes sense and be useful.

Regards,

I've retested the AuditApi.getAuditsQueryTransactionIdResults() just now, under the following conditions:

• Specifying a large pageSize: 500
• Specifying opts: { allowRedirect: true }
• The size of the audit events that would be returned exceeds the threshold (1MB?).
• My code then catches the exception, extracts the downloadUrl, and uses fetch() to retrieve the data.

It turns out that this is blocked due to CORS restrictions:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api-downloads.mypurecloud.com.au/audit-query-results/52759a62-9bf1-4f17-ab7a-0ea3deeda3bc/3e58c89e-e0e9-4126-afc7-183b38b1b31c-500?response-content-disposition=attachment%3Bfilename%3D%22Audit_Results%22&Expires=1780026090&Signature=...&Key-Pair-Id=K21FSGH5HMHI4N. (Reason: CORS header 'Access-Control-Allow-Origin' missing). Status code: 200.

Jerome, you mentioned that if the Location header had been returned in the initial response, the SDK running within a browser environment would have followed the redirect automatically (and couldn't be overridden in the code)? If so, that could only work if the second request (to api-downloads.mypurecloud.com.au) included CORS headers to allow access from anywhere? Do you think that is a reasonable thing to request (e.g. via support case)? Or do you think I would be wasting my time raising this?

Thanks,

Nick.

Hi Jerome.

Thanks for your insights.

I started out down the track of catching the exception, pulling out the downloadUrl, and then fetching the data from that URL. But then I struck a network error which at the time I assumed was CORS-related, but thinking more about it now, we had some Zscaler issues at the time which would almost certainly have impacted my testing, so I probably need to give this another shot. Anyway I ended up just reducing the pageSize to 100, and now it seems to work OK (but probably takes 5 times as long to retrieve all the data).

I'll do some more testing with this when I get time, and raise a support case based on my findings. Thanks for your help!

Nick.

Hi Jerome.

Yes the 302 response is being returned from the first getAuditsQueryTransactionIdResults call, which I see in my browser log as GET https://api.mypurecloud.com.au/api/v2/audits/query/2777ab34-2547-48d5-8b82-efdff84ceeb6/results?pageSize=1000&allowRedirect=true. The browser doesn't seem to show the response body for a 302 response, but I've added a console.log to the catch block surrounding the function call, and this is what is thrown, which I'm pretty sure is the response body:

{
  "id": "2777ab34-2547-48d5-8b82-efdff84ceeb6",
  "pageSize": 500,
  "cursor": "ATamPFwtceM9v2+X/Pcco4U3Adp80M1oTY9l+OVos/Uow8JqxxW4WBKV0ot1SR+UrGwJ07t1cGkK2t+iorEMmAkSSx/aArFkeA==",
  "downloadUrl": "https://api-downloads.mypurecloud.com.au/audit-query-results/52759a62-9bf1-4f17-ab7a-0ea3deeda3bc/2777ab34-2547-48d5-8b82-efdff84ceeb6-500?response-content-disposition=attachment%3Bfilename%3D%22Audit_Results%22&Expires=1786593597&Signature=...&Key-Pair-Id=K21FSGH5HMHI4N"
}

Note that I've removed the signature above and replaced it with "...".

BTW I haven't finished arguing with the developers about the addition of the Location header. They've gone quiet for over a week, so that could mean that they are giving this some more thought? With any luck they will change their mind and add the Location header and then you won't need to work around this issue?

Nick.

P.S. I think I sent a request for your contact details? If you are happy to provide your email address I can send you a HAR file containing the requests and responses up until the point that the 302 response is returned. However as I mentioned the body of the 302 response doesn't seem to be recorded by the browser, so this may not be very useful?

Hello Nick,

Unfortunately, I don't have that much influence.

But could you please tell me what HTTP Responses you are receiving in this scenario? I haven't been able to reproduce the 302. I have more than 500 audit entities in my test environment, but the response size is under 500 KB and does not seem to be enough to trigger the redirect scenario.

I'd like to understand if the 302 without the Location header is the first response you receive when calling getAuditsQueryTransactionIdResults (or if there is an intermediate redirect).

And more importantly, what the downloadUrl, that you receive in the 302 Response body, is. I mean if it is a Genesys Cloud url - like https://api.mypurecloud.com/something or even https://api.mypurecloud.com/api/v2/downloads/{downloadId} - or if it is a url that points to an S3.

I'd like to see if there is something I can do differently in the SDK to cope with this endpoint/scenario. It won't happen shortly (I mean not in the next days) but I'd like to check what/if I can do about it when I can.

Regards,

Hi Jerome.

The Genesys development team have added the CORS headers, but aren't prepared to add the Location header.

I tried to convince them that adding the Location header wasn't risky:

Can I please ask for clarification about why they think adding the Location header is risky? Because if they are worried about breaking existing code, then let us consider what the existing code would look like... i.e. Based on the old behaviour, existing code would follow one of these patterns:

a) Existing code may not include allowRedirect=true, in which case they are not impacted by what we are discussing;

b) Existing code may include allowRedirect=true, then catch an exception, and extract downloadUrl from the exception object, and fetch it (via a CORS proxy or similar to work around the missing CORS headers).

In scenario (b), it is expected that the addition of a Location header would result in the following behaviour: The SDK would (hopefully) process the 302 response, extract the Location header, and then fetch the resulting URL. The response that is returned would then be passed back as the result of the getAuditsQueryTransactionIdResults function. In other words from the program's perspective, it doesn't even know that there was a redirection - all it knows is it called the SDK function and got a result and no exception was thrown. In other words the program would follow exactly the same path as if the response had been small enough to be returned without the redirection.

(On the other hand, if the SDK doesn't handle the Location header in the way I've described, then the SDK will continue to throw the exception exactly the same as it does today, and the program will catch it and do exactly what it does today.)

In other words, I'd like to understand under what scenario could adding the Location header result in anything breaking?

But this is their response:

Adding the Location header is not a simple fix - the API layer currently passes through the response from the downstream service as-is. 
Constructing a proper Location header would require new logic to extract the signed URL (with query parameters) from the response body and format it as a header value. This changes the API response contract.
 
Additionally, the team considers that existing customers may have built solutions around the current behavior (302 with downloadUrl in body). 
Any change to how the 302 response is structured could affect those solutions in unpredictable ways.
 
The Location header enhancement is outside the scope of a bug fix and would need to go through the product enhancement process (via the Product Ideas Lab)

So it looks like a dead-end. Are there any strings you could pull on your side?

Thanks,

Hello,

Yes, that is worth reporting (and raising a ticket).

I mean mentioning that you can't download the file from a browser because of the lack of Access-Control-Allow-Origin on last endpoint. And at the same time mentioning that having the Location header present on first redirect would also makes sense and be useful.

Regards,

I've retested the AuditApi.getAuditsQueryTransactionIdResults() just now, under the following conditions:

• Specifying a large pageSize: 500
• Specifying opts: { allowRedirect: true }
• The size of the audit events that would be returned exceeds the threshold (1MB?).
• My code then catches the exception, extracts the downloadUrl, and uses fetch() to retrieve the data.

It turns out that this is blocked due to CORS restrictions:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api-downloads.mypurecloud.com.au/audit-query-results/52759a62-9bf1-4f17-ab7a-0ea3deeda3bc/3e58c89e-e0e9-4126-afc7-183b38b1b31c-500?response-content-disposition=attachment%3Bfilename%3D%22Audit_Results%22&Expires=1780026090&Signature=...&Key-Pair-Id=K21FSGH5HMHI4N. (Reason: CORS header 'Access-Control-Allow-Origin' missing). Status code: 200.

Jerome, you mentioned that if the Location header had been returned in the initial response, the SDK running within a browser environment would have followed the redirect automatically (and couldn't be overridden in the code)? If so, that could only work if the second request (to api-downloads.mypurecloud.com.au) included CORS headers to allow access from anywhere? Do you think that is a reasonable thing to request (e.g. via support case)? Or do you think I would be wasting my time raising this?

Thanks,

Nick.

Hi Jerome.

Thanks for your insights.

I started out down the track of catching the exception, pulling out the downloadUrl, and then fetching the data from that URL. But then I struck a network error which at the time I assumed was CORS-related, but thinking more about it now, we had some Zscaler issues at the time which would almost certainly have impacted my testing, so I probably need to give this another shot. Anyway I ended up just reducing the pageSize to 100, and now it seems to work OK (but probably takes 5 times as long to retrieve all the data).

I'll do some more testing with this when I get time, and raise a support case based on my findings. Thanks for your help!

Nick.

Hello Nick,

"BTW I haven't finished arguing with the developers about the addition of the Location header. They've gone quiet for over a week, so that could mean that they are giving this some more thought? With any luck they will change their mind and add the Location header and then you won't need to work around this issue?"

I don't know. I can't speak for them. Several people are out of office/on holidays at the moment.

I am not planning a change for this specifically yet. I mean not in next days or week. At this time, this is just to think about it to see if I can get something improved, that makes it easier to manage this scenario, and that doesn't introduce breaking changes.

I was thinking as a first step at providing an ApiError like content on 30x errors - I mean same structure than ApiErrors returned on 4xx/5xx errors (the 30x errors not being considered as an ApiError in the SDK). So that at least, status (302) could be checked on the catch(error) for getAuditsQueryTransactionIdResults.

"I think I sent a request for your contact details?"

Yep. I have accepted the contact request.

"However as I mentioned the body of the 302 response doesn't seem to be recorded by the browser, so this may not be very useful?"

I am still interested. Also to see what's in the headers.

What "bugs" me in the downloadUri is that it doesn't seem to be a Platform API endpoint - meaning the authorization token should not be sent. That's managed by axios automatically when there's a location header on the 302. I mean that just make the initial idea I have not applicable.

Regards,

Hi Jerome.

Yes the 302 response is being returned from the first getAuditsQueryTransactionIdResults call, which I see in my browser log as GET https://api.mypurecloud.com.au/api/v2/audits/query/2777ab34-2547-48d5-8b82-efdff84ceeb6/results?pageSize=1000&allowRedirect=true. The browser doesn't seem to show the response body for a 302 response, but I've added a console.log to the catch block surrounding the function call, and this is what is thrown, which I'm pretty sure is the response body:

{
  "id": "2777ab34-2547-48d5-8b82-efdff84ceeb6",
  "pageSize": 500,
  "cursor": "ATamPFwtceM9v2+X/Pcco4U3Adp80M1oTY9l+OVos/Uow8JqxxW4WBKV0ot1SR+UrGwJ07t1cGkK2t+iorEMmAkSSx/aArFkeA==",
  "downloadUrl": "https://api-downloads.mypurecloud.com.au/audit-query-results/52759a62-9bf1-4f17-ab7a-0ea3deeda3bc/2777ab34-2547-48d5-8b82-efdff84ceeb6-500?response-content-disposition=attachment%3Bfilename%3D%22Audit_Results%22&Expires=1786593597&Signature=...&Key-Pair-Id=K21FSGH5HMHI4N"
}

Note that I've removed the signature above and replaced it with "...".

BTW I haven't finished arguing with the developers about the addition of the Location header. They've gone quiet for over a week, so that could mean that they are giving this some more thought? With any luck they will change their mind and add the Location header and then you won't need to work around this issue?

Nick.

P.S. I think I sent a request for your contact details? If you are happy to provide your email address I can send you a HAR file containing the requests and responses up until the point that the 302 response is returned. However as I mentioned the body of the 302 response doesn't seem to be recorded by the browser, so this may not be very useful?

Hello Nick,

Unfortunately, I don't have that much influence.

But could you please tell me what HTTP Responses you are receiving in this scenario? I haven't been able to reproduce the 302. I have more than 500 audit entities in my test environment, but the response size is under 500 KB and does not seem to be enough to trigger the redirect scenario.

I'd like to understand if the 302 without the Location header is the first response you receive when calling getAuditsQueryTransactionIdResults (or if there is an intermediate redirect).

And more importantly, what the downloadUrl, that you receive in the 302 Response body, is. I mean if it is a Genesys Cloud url - like https://api.mypurecloud.com/something or even https://api.mypurecloud.com/api/v2/downloads/{downloadId} - or if it is a url that points to an S3.

I'd like to see if there is something I can do differently in the SDK to cope with this endpoint/scenario. It won't happen shortly (I mean not in the next days) but I'd like to check what/if I can do about it when I can.

Regards,

Hi Jerome.

The Genesys development team have added the CORS headers, but aren't prepared to add the Location header.

I tried to convince them that adding the Location header wasn't risky:

Can I please ask for clarification about why they think adding the Location header is risky? Because if they are worried about breaking existing code, then let us consider what the existing code would look like... i.e. Based on the old behaviour, existing code would follow one of these patterns:

a) Existing code may not include allowRedirect=true, in which case they are not impacted by what we are discussing;

b) Existing code may include allowRedirect=true, then catch an exception, and extract downloadUrl from the exception object, and fetch it (via a CORS proxy or similar to work around the missing CORS headers).

In scenario (b), it is expected that the addition of a Location header would result in the following behaviour: The SDK would (hopefully) process the 302 response, extract the Location header, and then fetch the resulting URL. The response that is returned would then be passed back as the result of the getAuditsQueryTransactionIdResults function. In other words from the program's perspective, it doesn't even know that there was a redirection - all it knows is it called the SDK function and got a result and no exception was thrown. In other words the program would follow exactly the same path as if the response had been small enough to be returned without the redirection.

(On the other hand, if the SDK doesn't handle the Location header in the way I've described, then the SDK will continue to throw the exception exactly the same as it does today, and the program will catch it and do exactly what it does today.)

In other words, I'd like to understand under what scenario could adding the Location header result in anything breaking?

But this is their response:

Adding the Location header is not a simple fix - the API layer currently passes through the response from the downstream service as-is. 
Constructing a proper Location header would require new logic to extract the signed URL (with query parameters) from the response body and format it as a header value. This changes the API response contract.
 
Additionally, the team considers that existing customers may have built solutions around the current behavior (302 with downloadUrl in body). 
Any change to how the 302 response is structured could affect those solutions in unpredictable ways.
 
The Location header enhancement is outside the scope of a bug fix and would need to go through the product enhancement process (via the Product Ideas Lab)

So it looks like a dead-end. Are there any strings you could pull on your side?

Thanks,

Hello,

Yes, that is worth reporting (and raising a ticket).

I mean mentioning that you can't download the file from a browser because of the lack of Access-Control-Allow-Origin on last endpoint. And at the same time mentioning that having the Location header present on first redirect would also makes sense and be useful.

Regards,

I've retested the AuditApi.getAuditsQueryTransactionIdResults() just now, under the following conditions:

• Specifying a large pageSize: 500
• Specifying opts: { allowRedirect: true }
• The size of the audit events that would be returned exceeds the threshold (1MB?).
• My code then catches the exception, extracts the downloadUrl, and uses fetch() to retrieve the data.

It turns out that this is blocked due to CORS restrictions:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api-downloads.mypurecloud.com.au/audit-query-results/52759a62-9bf1-4f17-ab7a-0ea3deeda3bc/3e58c89e-e0e9-4126-afc7-183b38b1b31c-500?response-content-disposition=attachment%3Bfilename%3D%22Audit_Results%22&Expires=1780026090&Signature=...&Key-Pair-Id=K21FSGH5HMHI4N. (Reason: CORS header 'Access-Control-Allow-Origin' missing). Status code: 200.

Jerome, you mentioned that if the Location header had been returned in the initial response, the SDK running within a browser environment would have followed the redirect automatically (and couldn't be overridden in the code)? If so, that could only work if the second request (to api-downloads.mypurecloud.com.au) included CORS headers to allow access from anywhere? Do you think that is a reasonable thing to request (e.g. via support case)? Or do you think I would be wasting my time raising this?

Thanks,

Nick.

Hi Jerome.

Thanks for your insights.

I started out down the track of catching the exception, pulling out the downloadUrl, and then fetching the data from that URL. But then I struck a network error which at the time I assumed was CORS-related, but thinking more about it now, we had some Zscaler issues at the time which would almost certainly have impacted my testing, so I probably need to give this another shot. Anyway I ended up just reducing the pageSize to 100, and now it seems to work OK (but probably takes 5 times as long to retrieve all the data).

I'll do some more testing with this when I get time, and raise a support case based on my findings. Thanks for your help!

Nick.

I've sent you a message whose body is the HAR file content from my test yesterday.

> What "bugs" me in the downloadUri is that it doesn't seem to be a Platform API endpoint - meaning the authorization token should not be sent. That's managed by axios automatically when there's a location header on the 302. I mean that just make the initial idea I have not applicable.

The downloadUri appears to be a signed S3 URL so you don't need to supply an Authorization header. (I'm not sure what the lifespan of the signed URL is though... Most likely the one in the HAR file may have expired already? But I think you only needed to see what was going on up to the point where the 302 occurs?)

Hello Nick,

"BTW I haven't finished arguing with the developers about the addition of the Location header. They've gone quiet for over a week, so that could mean that they are giving this some more thought? With any luck they will change their mind and add the Location header and then you won't need to work around this issue?"

I don't know. I can't speak for them. Several people are out of office/on holidays at the moment.

I am not planning a change for this specifically yet. I mean not in next days or week. At this time, this is just to think about it to see if I can get something improved, that makes it easier to manage this scenario, and that doesn't introduce breaking changes.

I was thinking as a first step at providing an ApiError like content on 30x errors - I mean same structure than ApiErrors returned on 4xx/5xx errors (the 30x errors not being considered as an ApiError in the SDK). So that at least, status (302) could be checked on the catch(error) for getAuditsQueryTransactionIdResults.

"I think I sent a request for your contact details?"

Yep. I have accepted the contact request.

"However as I mentioned the body of the 302 response doesn't seem to be recorded by the browser, so this may not be very useful?"

I am still interested. Also to see what's in the headers.

What "bugs" me in the downloadUri is that it doesn't seem to be a Platform API endpoint - meaning the authorization token should not be sent. That's managed by axios automatically when there's a location header on the 302. I mean that just make the initial idea I have not applicable.

Regards,

Hi Jerome.

Yes the 302 response is being returned from the first getAuditsQueryTransactionIdResults call, which I see in my browser log as GET https://api.mypurecloud.com.au/api/v2/audits/query/2777ab34-2547-48d5-8b82-efdff84ceeb6/results?pageSize=1000&allowRedirect=true. The browser doesn't seem to show the response body for a 302 response, but I've added a console.log to the catch block surrounding the function call, and this is what is thrown, which I'm pretty sure is the response body:

{
  "id": "2777ab34-2547-48d5-8b82-efdff84ceeb6",
  "pageSize": 500,
  "cursor": "ATamPFwtceM9v2+X/Pcco4U3Adp80M1oTY9l+OVos/Uow8JqxxW4WBKV0ot1SR+UrGwJ07t1cGkK2t+iorEMmAkSSx/aArFkeA==",
  "downloadUrl": "https://api-downloads.mypurecloud.com.au/audit-query-results/52759a62-9bf1-4f17-ab7a-0ea3deeda3bc/2777ab34-2547-48d5-8b82-efdff84ceeb6-500?response-content-disposition=attachment%3Bfilename%3D%22Audit_Results%22&Expires=1786593597&Signature=...&Key-Pair-Id=K21FSGH5HMHI4N"
}

Note that I've removed the signature above and replaced it with "...".

BTW I haven't finished arguing with the developers about the addition of the Location header. They've gone quiet for over a week, so that could mean that they are giving this some more thought? With any luck they will change their mind and add the Location header and then you won't need to work around this issue?

Nick.

P.S. I think I sent a request for your contact details? If you are happy to provide your email address I can send you a HAR file containing the requests and responses up until the point that the 302 response is returned. However as I mentioned the body of the 302 response doesn't seem to be recorded by the browser, so this may not be very useful?

Hello Nick,

Unfortunately, I don't have that much influence.

But could you please tell me what HTTP Responses you are receiving in this scenario? I haven't been able to reproduce the 302. I have more than 500 audit entities in my test environment, but the response size is under 500 KB and does not seem to be enough to trigger the redirect scenario.

I'd like to understand if the 302 without the Location header is the first response you receive when calling getAuditsQueryTransactionIdResults (or if there is an intermediate redirect).

And more importantly, what the downloadUrl, that you receive in the 302 Response body, is. I mean if it is a Genesys Cloud url - like https://api.mypurecloud.com/something or even https://api.mypurecloud.com/api/v2/downloads/{downloadId} - or if it is a url that points to an S3.

I'd like to see if there is something I can do differently in the SDK to cope with this endpoint/scenario. It won't happen shortly (I mean not in the next days) but I'd like to check what/if I can do about it when I can.

Regards,

Hi Jerome.

The Genesys development team have added the CORS headers, but aren't prepared to add the Location header.

I tried to convince them that adding the Location header wasn't risky:

Can I please ask for clarification about why they think adding the Location header is risky? Because if they are worried about breaking existing code, then let us consider what the existing code would look like... i.e. Based on the old behaviour, existing code would follow one of these patterns:

a) Existing code may not include allowRedirect=true, in which case they are not impacted by what we are discussing;

b) Existing code may include allowRedirect=true, then catch an exception, and extract downloadUrl from the exception object, and fetch it (via a CORS proxy or similar to work around the missing CORS headers).

In scenario (b), it is expected that the addition of a Location header would result in the following behaviour: The SDK would (hopefully) process the 302 response, extract the Location header, and then fetch the resulting URL. The response that is returned would then be passed back as the result of the getAuditsQueryTransactionIdResults function. In other words from the program's perspective, it doesn't even know that there was a redirection - all it knows is it called the SDK function and got a result and no exception was thrown. In other words the program would follow exactly the same path as if the response had been small enough to be returned without the redirection.

(On the other hand, if the SDK doesn't handle the Location header in the way I've described, then the SDK will continue to throw the exception exactly the same as it does today, and the program will catch it and do exactly what it does today.)

In other words, I'd like to understand under what scenario could adding the Location header result in anything breaking?

But this is their response:

Adding the Location header is not a simple fix - the API layer currently passes through the response from the downstream service as-is. 
Constructing a proper Location header would require new logic to extract the signed URL (with query parameters) from the response body and format it as a header value. This changes the API response contract.
 
Additionally, the team considers that existing customers may have built solutions around the current behavior (302 with downloadUrl in body). 
Any change to how the 302 response is structured could affect those solutions in unpredictable ways.
 
The Location header enhancement is outside the scope of a bug fix and would need to go through the product enhancement process (via the Product Ideas Lab)

So it looks like a dead-end. Are there any strings you could pull on your side?

Thanks,

Hello,

Yes, that is worth reporting (and raising a ticket).

I mean mentioning that you can't download the file from a browser because of the lack of Access-Control-Allow-Origin on last endpoint. And at the same time mentioning that having the Location header present on first redirect would also makes sense and be useful.

Regards,

I've retested the AuditApi.getAuditsQueryTransactionIdResults() just now, under the following conditions:

• Specifying a large pageSize: 500
• Specifying opts: { allowRedirect: true }
• The size of the audit events that would be returned exceeds the threshold (1MB?).
• My code then catches the exception, extracts the downloadUrl, and uses fetch() to retrieve the data.

It turns out that this is blocked due to CORS restrictions:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api-downloads.mypurecloud.com.au/audit-query-results/52759a62-9bf1-4f17-ab7a-0ea3deeda3bc/3e58c89e-e0e9-4126-afc7-183b38b1b31c-500?response-content-disposition=attachment%3Bfilename%3D%22Audit_Results%22&Expires=1780026090&Signature=...&Key-Pair-Id=K21FSGH5HMHI4N. (Reason: CORS header 'Access-Control-Allow-Origin' missing). Status code: 200.

Jerome, you mentioned that if the Location header had been returned in the initial response, the SDK running within a browser environment would have followed the redirect automatically (and couldn't be overridden in the code)? If so, that could only work if the second request (to api-downloads.mypurecloud.com.au) included CORS headers to allow access from anywhere? Do you think that is a reasonable thing to request (e.g. via support case)? Or do you think I would be wasting my time raising this?

Thanks,

Nick.

Hi Jerome.

Thanks for your insights.

I started out down the track of catching the exception, pulling out the downloadUrl, and then fetching the data from that URL. But then I struck a network error which at the time I assumed was CORS-related, but thinking more about it now, we had some Zscaler issues at the time which would almost certainly have impacted my testing, so I probably need to give this another shot. Anyway I ended up just reducing the pageSize to 100, and now it seems to work OK (but probably takes 5 times as long to retrieve all the data).

I'll do some more testing with this when I get time, and raise a support case based on my findings. Thanks for your help!

Nick.