Thanks for the reply!

I was thinking there is some config to set up in APIMan, but the problem was not there. My backend server is not adding the Content-Length, so the server add Transfer-Encoding as Chunked in the Response-Header (now I understand what's going on!).

So, what I do was add the HTTP Header Policy Plugin, and then added "Transfer-Encoding" in the Strip Headers fields, as the image below:

​

I believe this is not the best thing to do but works for me for while. I'll add the Content-Length in service to solve it!

2017-01-03 16:03 GMT-03:00 Marc Savy <marc.savy@redhat.com>:
Replying to list.


This going to help me a lot! I'm still planning to update my apiman instance. Could I just remove my old version (1.2.3) and then deploy the new one with my configurations files?

Yes, that should work fine. You might want to build from master, considering the bug you encountered. I'll see if it's possible to at least do a snapshot release soon. People are on holiday at the moment.

How to avoid chunked encoding when the rest api is passing through APIMan?
 
At present we use chunked encoding[1] because it's much simpler when handling mutable streaming payloads - especially if we're doing a transformation where it is not be clear what the final payload size will be until the process is completed (which would cause substantial buffering).

That being said, in the case of a pipeline where no body mutation policies exist, we could consider setting content-length. I'll have to think about it to consider whether there are any important implications. This would be a feature request.

How to consume a service with chunked-encoding transfer in java using Jersey Framework

Chunked encoding has been supported since HTTP/1.1, unless you are using an extremely old/buggy version of Jersey it should work fine. It should be pretty much transparent in practice.

Your bug might be something else. I suggest trying the latest release and then filing a JIRA with full information (e.g. expected vs actual; console output; configuration). 

Maybe this is happen for that reason -> APIMAN 984

I don't think you are using the policy mentioned in that ticket, are you?

For now, I do not found any ways to workaround that issue, so I think I'm gonna create a policy / plugin to solve that, just to adding a response header setting the Content-Length on header. I don't know if it is a good idea, but maybe could solve this for while.

You may be able to do that, but it would require buffering which will reduce performance. It may also be tricky to determine from within the policy which is the final chunk of a stream (with small payloads it's likely just 1 chunk, though). 
 
On 2 January 2017 at 22:12, Celso Agra <celso.agra@gmail.com> wrote:
Thanks Marc!

This going to help me a lot! I'm still planning to update my apiman instance. Could I just remove my old version (1.2.3) and then deploy the new one with my configurations files? 
For now, I do not found any ways to workaround that issue, so I think I'm gonna create a policy / plugin to solve that, just to adding a response header setting the Content-Length on header. I don't know if it is a good idea, but maybe could solve this for while. 

Thanks for your help Marc!


2017-01-02 17:04 GMT-03:00 Marc Savy <marc.savy@redhat.com>:
I addressed this for Celso over JIRA.

Summary:

- In general, if you're using CORS you should probably use the query parameter to transmit your access token (if you have one). This is because of a limitation to CORS preflight request phase which never transmits custom headers.

- A separate issue was a bug (now fixed on master) where a data structure would cause certain header-value fields to be mixed up in specific circumstances.

On 28 December 2016 at 14:10, Celso Agra <celso.agra@gmail.com> wrote:
Hi all,

It's me again!
So, I was looking for some solutions about my issue, and I found this: https://issues.jboss.org/browse/APIMAN-516

It seems this issue still occurs with me. I tries to send some headers via ajax, and get this response:
XMLHttpRequest cannot load https://apiman.url. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://192.168.56.22:8080' is therefore not allowed access. The response had HTTP status code 500.

Here is the Response Headers:
Connection:close
Content-Type:application/json
Date:Wed, 28 Dec 2016 13:54:08 GMT
Server:Apache/2.4.18 (Ubuntu)
Transfer-Encoding:chunked
X-Gateway-Error:API not public.
X-Powered-By:Undertow/1

and

Here is the Request Headers:
Accept:*/*
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4
Access-Control-Request-Headers:authorization, x-api-key
Access-Control-Request-Method:GET
Connection:keep-alive
Host: apiman.url
Origin:http://192.168.56.22:8080
Referer:http://192.168.56.22:8080/app
User-Agent:Mozilla/5.0 ...
Query String Parameters
view source
view URL encoded

Does anyone has the same problem?

Best regards,

--
---
Celso Agra

_______________________________________________
Apiman-user mailing list
Apiman-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user





--
---
Celso Agra




--
---
Celso Agra