[Apiman-user] How to configure CORS in APIMan? Problems with Headers in ajax

Thu Jan 19 12:43:23 EST 2017

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 at 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 at 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-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
>>> <http://stackoverflow.com/questions/41432329/how-to-consume-a-service-with-chunked-encoding-transfer-in-java-using-jersey-fra>
>>
>>
>> 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 at 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-when-the-rest-api-is-passing-through-apiman>
>>>    - 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-transfer-in-java-using-jersey-fra>
>>>
>>> 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 at 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 at 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> ---
>>> *Celso Agra*
>>>
>>
>>
>
>
> --
> ---
> *Celso Agra*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170119/c64b690b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apiman images.png
Type: image/png
Size: 17124 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170119/c64b690b/attachment-0001.png 