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? > <http://stackoverflow.com/questions/41385736/how-to-avoid-chunked-encoding... 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 > <http://stackoverflow.com/questions/41432329/how-to-consume-a-service-with... 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 > <https://issues.jboss.org/browse/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(a)gmail.com&gt; 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? > > Just to let you know... I believe I got another issue with apiman: > > - How to avoid chunked encoding when the rest api is passing through > APIMan? > <http://stackoverflow.com/questions/41385736/how-to-avoid-chunked-encoding... > - How to consume a service with chunked-encoding transfer in java > using Jersey Framework > <http://stackoverflow.com/questions/41432329/how-to-consume-a-service-with... > > Maybe this is happen for that reason -> APIMAN 984 > <https://issues.jboss.org/browse/APIMAN-984> > 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(a)redhat.com&gt;: > >> 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(a)gmail.com&gt; 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/apiman-user >>> >>> >> > > > -- > --- > *Celso Agra* >

If you build from master you should be able to see Content-Length now if you're not using any body mutating policies. On 3 January 2017 at 19:41, Celso Agra <celso.agra(a)gmail.com&gt; wrote: > 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(a)redhat.com&gt;: > >> 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? >>> <http://stackoverflow.com/questions/41385736/how-to-avoid-chunked-encoding... >> >> >> 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 >>> <http://stackoverflow.com/questions/41432329/how-to-consume-a-service-with... >> >> >> 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 >>> <https://issues.jboss.org/browse/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(a)gmail.com&gt; 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? >>> >> >>> Just to let you know... I believe I got another issue with apiman: >>> >>> - How to avoid chunked encoding when the rest api is passing >>> through APIMan? >>> <http://stackoverflow.com/questions/41385736/how-to-avoid-chunked-encoding... >>> - How to consume a service with chunked-encoding transfer in java >>> using Jersey Framework >>> <http://stackoverflow.com/questions/41432329/how-to-consume-a-service-with... >>> >>> Maybe this is happen for that reason -> APIMAN 984 >>> <https://issues.jboss.org/browse/APIMAN-984> >>> >> 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(a)redhat.com&gt;: >>> >>>> 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(a)gmail.com&gt; 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/apiman-user >>>>> >>>>> >>>> >>> >>> >>> -- >>> --- >>> *Celso Agra* >>> >> >> > > > -- > --- > *Celso Agra* >