Great!
Thanks, Marc.
2017-01-19 14:43 GMT-03:00 Marc Savy <marc.savy(a)redhat.com>:
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> 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>:
>
>> 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> 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>:
>>>
>>>> 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>
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*
>