8:14 a.m.
A client-side javascript app is performing the following request:
*DELETE /apiman-gateway/org/service/1.1/resource/7 HTTP/1.1Host:
172.17.0.1:8080 <http://172.17.0.1:8080>User-Agent: Mozilla/5.0 (X11;
Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0Accept:
application/json, text/plain, */*Accept-Language:
en-US,en;q=0.5Accept-Encoding: gzip, deflateAuthorization: Bearer
$ACCESS_TOKENReferer: http://172.17.0.1:3000/
<http://172.17.0.1:3000/>Origin: http://172.17.0.1:3000
<http://172.17.0.1:3000>Connection: keep-alive*
But the gateway is performing the following request to the endpoint:
*DELETE /service/rest/resource/7 HTTP/1.1User-Agent: Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; SV1)Origin: http://172.17.0.1:3000
<http://172.17.0.1:3000>Accept-Language: en-US,en;q=0.5Accept-Encoding:
gzip, deflateConnection: keep-aliveAuthorization: Bearer
$ACCESS_TOKENAccept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/msword,
application/vnd.ms-powerpoint, */*Referer: http://172.17.0.1:3000/
<http://172.17.0.1:3000/>Host: 172.17.0.1:8280
<http://172.17.0.1:8280>Content-Type: application/x-www-form-*
*urlencodedContent-Length: 0*
Resulting in a 415 Unsupported Media Type at the endpoint.
GET, POST and PUT requests are OK.
Only using CORS Policy for this endpoint:
*Access-Control-Allow-Origin: *Access-Control-Allow-Credentials:
trueAccess-Control-Allow-Headers: accept, authrotization,
content-typeAccess-Control-Allow-Methods: GET, POST, PUT,
DELETEAccess-Control-Max-Age: 3600*
8:49 a.m.
JIRA issue created. In case you want to track it:
https://issues.jboss.org/browse/APIMAN-1210
-Eric
On 7/25/2016 9:14 AM, Jairo Junior wrote:
A client-side javascript app is performing the following request:
/DELETE /apiman-gateway/org/service/1.1/resource/7 HTTP/1.1
Host: 172.17.0.1:8080 <http://172.17.0.1:8080>
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0)
Gecko/20100101 Firefox/47.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Authorization: Bearer $ACCESS_TOKEN
Referer: http://172.17.0.1:3000/
Origin: http://172.17.0.1:3000
Connection: keep-alive
/
But the gateway is performing the following request to the endpoint:
/DELETE /service/rest/resource/7 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Origin: http://172.17.0.1:3000
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Authorization: Bearer $ACCESS_TOKEN
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/msword,
application/vnd.ms-powerpoint, */*
Referer: http://172.17.0.1:3000/
Host: 172.17.0.1:8280 <http://172.17.0.1:8280>
Content-Type: application/x-www-form-//urlencoded
Content-Length: 0
/
Resulting in a 415 Unsupported Media Type at the endpoint.
GET, POST and PUT requests are OK.
Only using CORS Policy for this endpoint:
/Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: accept, authrotization, content-type
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Max-Age: 3600/
_______________________________________________
Apiman-user mailing list
Apiman-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user
9:06 a.m.
Thanks again.
On Mon, Jul 25, 2016 at 10:49 AM Eric Wittmann <eric.wittmann(a)redhat.com>
wrote:
JIRA issue created. In case you want to track it:
https://issues.jboss.org/browse/APIMAN-1210
-Eric
On 7/25/2016 9:14 AM, Jairo Junior wrote:
> A client-side javascript app is performing the following request:
>
> /DELETE /apiman-gateway/org/service/1.1/resource/7 HTTP/1.1
> Host: 172.17.0.1:8080 <http://172.17.0.1:8080>
> User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0)
> Gecko/20100101 Firefox/47.0
> Accept: application/json, text/plain, */*
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate
> Authorization: Bearer $ACCESS_TOKEN
> Referer: http://172.17.0.1:3000/
> Origin: http://172.17.0.1:3000
> Connection: keep-alive
>
> /
> But the gateway is performing the following request to the endpoint:
>
> /DELETE /service/rest/resource/7 HTTP/1.1
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
> Origin: http://172.17.0.1:3000
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate
> Connection: keep-alive
> Authorization: Bearer $ACCESS_TOKEN
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/vnd.ms-excel, application/msword,
> application/vnd.ms-powerpoint, */*
> Referer: http://172.17.0.1:3000/
> Host: 172.17.0.1:8280 <http://172.17.0.1:8280>
> Content-Type: application/x-www-form-//urlencoded
> Content-Length: 0
>
> /
> Resulting in a 415 Unsupported Media Type at the endpoint.
>
> GET, POST and PUT requests are OK.
>
> Only using CORS Policy for this endpoint:
>
> /Access-Control-Allow-Origin: *
> Access-Control-Allow-Credentials: true
> Access-Control-Allow-Headers: accept, authrotization, content-type
> Access-Control-Allow-Methods: GET, POST, PUT, DELETE
> Access-Control-Max-Age: 3600/
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
7:53 a.m.
Question: what is the consequence of this problem?
It turns out that fixing this issue may require fairly extensive changes
to how apiman proxies the request to the back end API. The
http client[1] we are using for this is adding the content length and
content type automatically for DELETE (as well as PUT and POST) if they
are missing. It's doing this because it claims the HTTP spec is
ambiguous on whether DELETE can have a body.
So how high a priority is this? Is it causing a specific problem for
you, or is it simply something you noticed?
-Eric
[1] http://square.github.io/okhttp/
On 7/25/2016 10:06 AM, Jairo Junior wrote:
Thanks again.
On Mon, Jul 25, 2016 at 10:49 AM Eric Wittmann <eric.wittmann(a)redhat.com
<mailto:eric.wittmann@redhat.com>> wrote:
JIRA issue created. In case you want to track it:
https://issues.jboss.org/browse/APIMAN-1210
-Eric
On 7/25/2016 9:14 AM, Jairo Junior wrote:
> A client-side javascript app is performing the following request:
>
> /DELETE /apiman-gateway/org/service/1.1/resource/7 HTTP/1.1
> Host: 172.17.0.1:8080 <http://172.17.0.1:8080>
<http://172.17.0.1:8080>
> User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0)
> Gecko/20100101 Firefox/47.0
> Accept: application/json, text/plain, */*
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate
> Authorization: Bearer $ACCESS_TOKEN
> Referer: http://172.17.0.1:3000/
> Origin: http://172.17.0.1:3000
> Connection: keep-alive
>
> /
> But the gateway is performing the following request to the endpoint:
>
> /DELETE /service/rest/resource/7 HTTP/1.1
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
> Origin: http://172.17.0.1:3000
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate
> Connection: keep-alive
> Authorization: Bearer $ACCESS_TOKEN
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/vnd.ms-excel, application/msword,
> application/vnd.ms-powerpoint, */*
> Referer: http://172.17.0.1:3000/
> Host: 172.17.0.1:8280 <http://172.17.0.1:8280>
<http://172.17.0.1:8280>
> Content-Type: application/x-www-form-//urlencoded
> Content-Length: 0
>
> /
> Resulting in a 415 Unsupported Media Type at the endpoint.
>
> GET, POST and PUT requests are OK.
>
> Only using CORS Policy for this endpoint:
>
> /Access-Control-Allow-Origin: *
> Access-Control-Allow-Credentials: true
> Access-Control-Allow-Headers: accept, authrotization, content-type
> Access-Control-Allow-Methods: GET, POST, PUT, DELETE
> Access-Control-Max-Age: 3600/
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
8:30 a.m.
It results in a "415 Unsupported Media Type" at the endpoint, since it
wasn't designed to consume application/x-www-form-urlencoded.
I have experience with some ESB's, and, in most cases, when you have a
proxy that is "too smart" it may break your endpoint behavior. And when we
are talking about REST APIs, where we are using HTTP as both a transport
and application protocol, any apiman interference may break behavior. It's
OK for new APIs, but it's very bad for legacy.
IMHO, if the gateway is deliberately including headers, there won't be any
guarantees that the endpoint will be prepared for this. There is a general
discussion in Microservices community regarding Smart Pipe X Dumb Pipe that
is very relevant to what we are discussing here.
Also, I thinkg okhttp is the best alternative when you're developing a
client, but is it good to proxy requests? Have you considered Apache HTTP
Client + PoolingHttpClientConnectionManager. It has some nice features like
"per route" connection pooling that will probably be killing for a Gateway.
On Tue, Jul 26, 2016 at 9:53 AM Eric Wittmann <eric.wittmann(a)redhat.com>
wrote:
Question: what is the consequence of this problem?
It turns out that fixing this issue may require fairly extensive changes
to how apiman proxies the request to the back end API. The
http client[1] we are using for this is adding the content length and
content type automatically for DELETE (as well as PUT and POST) if they
are missing. It's doing this because it claims the HTTP spec is
ambiguous on whether DELETE can have a body.
So how high a priority is this? Is it causing a specific problem for
you, or is it simply something you noticed?
-Eric
[1] http://square.github.io/okhttp/
On 7/25/2016 10:06 AM, Jairo Junior wrote:
> Thanks again.
>
> On Mon, Jul 25, 2016 at 10:49 AM Eric Wittmann <eric.wittmann(a)redhat.com
> <mailto:eric.wittmann@redhat.com>> wrote:
>
> JIRA issue created. In case you want to track it:
>
> https://issues.jboss.org/browse/APIMAN-1210
>
> -Eric
>
> On 7/25/2016 9:14 AM, Jairo Junior wrote:
> > A client-side javascript app is performing the following request:
> >
> > /DELETE /apiman-gateway/org/service/1.1/resource/7 HTTP/1.1
> > Host: 172.17.0.1:8080 <http://172.17.0.1:8080>
> <http://172.17.0.1:8080>
> > User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0)
> > Gecko/20100101 Firefox/47.0
> > Accept: application/json, text/plain, */*
> > Accept-Language: en-US,en;q=0.5
> > Accept-Encoding: gzip, deflate
> > Authorization: Bearer $ACCESS_TOKEN
> > Referer: http://172.17.0.1:3000/
> > Origin: http://172.17.0.1:3000
> > Connection: keep-alive
> >
> > /
> > But the gateway is performing the following request to the
endpoint:
> >
> > /DELETE /service/rest/resource/7 HTTP/1.1
> > User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
> > Origin: http://172.17.0.1:3000
> > Accept-Language: en-US,en;q=0.5
> > Accept-Encoding: gzip, deflate
> > Connection: keep-alive
> > Authorization: Bearer $ACCESS_TOKEN
> > Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> > application/vnd.ms-excel, application/msword,
> > application/vnd.ms-powerpoint, */*
> > Referer: http://172.17.0.1:3000/
> > Host: 172.17.0.1:8280 <http://172.17.0.1:8280>
> <http://172.17.0.1:8280>
> > Content-Type: application/x-www-form-//urlencoded
> > Content-Length: 0
> >
> > /
> > Resulting in a 415 Unsupported Media Type at the endpoint.
> >
> > GET, POST and PUT requests are OK.
> >
> > Only using CORS Policy for this endpoint:
> >
> > /Access-Control-Allow-Origin: *
> > Access-Control-Allow-Credentials: true
> > Access-Control-Allow-Headers: accept, authrotization, content-type
> > Access-Control-Allow-Methods: GET, POST, PUT, DELETE
> > Access-Control-Max-Age: 3600/
> >
> >
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
>
8:49 a.m.
OK thanks for the info - very helpful.
Regarding OK vs Apache - there is a design reason why OK is being used
vs. Apache that is perhaps not that interesting to get into. It has to
do with the way in which we stream the body of the request (and response).
I agree with the assessment of smart vs. dumb proxies - the apiman
gateway should definitely not be adding anything to the conversation
that wasn't configured via one of the policies. I definitely consider
this a bug, but I think it may require a fairly substantial rewrite of
the http connector to fix it. :( I'm not against doing it, but I was
hoping for a quick fix.
-Eric
On 7/26/2016 9:30 AM, Jairo Junior wrote:
It results in a "415 Unsupported Media Type" at the
endpoint, since it
wasn't designed to consume application/x-www-form-urlencoded.
I have experience with some ESB's, and, in most cases, when you have a
proxy that is "too smart" it may break your endpoint behavior. And when
we are talking about REST APIs, where we are using HTTP as both a
transport and application protocol, any apiman interference may break
behavior. It's OK for new APIs, but it's very bad for legacy.
IMHO, if the gateway is deliberately including headers, there won't be
any guarantees that the endpoint will be prepared for this. There is a
general discussion in Microservices community regarding Smart Pipe X
Dumb Pipe that is very relevant to what we are discussing here.
Also, I thinkg okhttp is the best alternative when you're developing a
client, but is it good to proxy requests? Have you considered Apache
HTTP Client + PoolingHttpClientConnectionManager. It has some nice
features like "per route" connection pooling that will probably be
killing for a Gateway.
On Tue, Jul 26, 2016 at 9:53 AM Eric Wittmann <eric.wittmann(a)redhat.com
<mailto:eric.wittmann@redhat.com>> wrote:
Question: what is the consequence of this problem?
It turns out that fixing this issue may require fairly extensive changes
to how apiman proxies the request to the back end API. The
http client[1] we are using for this is adding the content length and
content type automatically for DELETE (as well as PUT and POST) if they
are missing. It's doing this because it claims the HTTP spec is
ambiguous on whether DELETE can have a body.
So how high a priority is this? Is it causing a specific problem for
you, or is it simply something you noticed?
-Eric
[1] http://square.github.io/okhttp/
On 7/25/2016 10:06 AM, Jairo Junior wrote:
> Thanks again.
>
> On Mon, Jul 25, 2016 at 10:49 AM Eric Wittmann
<eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com>
> <mailto:eric.wittmann@redhat.com
<mailto:eric.wittmann@redhat.com>>> wrote:
>
> JIRA issue created. In case you want to track it:
>
> https://issues.jboss.org/browse/APIMAN-1210
>
> -Eric
>
> On 7/25/2016 9:14 AM, Jairo Junior wrote:
> > A client-side javascript app is performing the following
request:
> >
> > /DELETE /apiman-gateway/org/service/1.1/resource/7 HTTP/1.1
> > Host: 172.17.0.1:8080 <http://172.17.0.1:8080>
<http://172.17.0.1:8080>
> <http://172.17.0.1:8080>
> > User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0)
> > Gecko/20100101 Firefox/47.0
> > Accept: application/json, text/plain, */*
> > Accept-Language: en-US,en;q=0.5
> > Accept-Encoding: gzip, deflate
> > Authorization: Bearer $ACCESS_TOKEN
> > Referer: http://172.17.0.1:3000/
> > Origin: http://172.17.0.1:3000
> > Connection: keep-alive
> >
> > /
> > But the gateway is performing the following request to the
endpoint:
> >
> > /DELETE /service/rest/resource/7 HTTP/1.1
> > User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
5.1; SV1)
> > Origin: http://172.17.0.1:3000
> > Accept-Language: en-US,en;q=0.5
> > Accept-Encoding: gzip, deflate
> > Connection: keep-alive
> > Authorization: Bearer $ACCESS_TOKEN
> > Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> > application/vnd.ms-excel, application/msword,
> > application/vnd.ms-powerpoint, */*
> > Referer: http://172.17.0.1:3000/
> > Host: 172.17.0.1:8280 <http://172.17.0.1:8280>
<http://172.17.0.1:8280>
> <http://172.17.0.1:8280>
> > Content-Type: application/x-www-form-//urlencoded
> > Content-Length: 0
> >
> > /
> > Resulting in a 415 Unsupported Media Type at the endpoint.
> >
> > GET, POST and PUT requests are OK.
> >
> > Only using CORS Policy for this endpoint:
> >
> > /Access-Control-Allow-Origin: *
> > Access-Control-Allow-Credentials: true
> > Access-Control-Allow-Headers: accept, authrotization,
content-type
> > Access-Control-Allow-Methods: GET, POST, PUT, DELETE
> > Access-Control-Max-Age: 3600/
> >
> >
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user(a)lists.jboss.org
<mailto:Apiman-user@lists.jboss.org>
<mailto:Apiman-user@lists.jboss.org
<mailto:Apiman-user@lists.jboss.org>>
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
>
4:53 p.m.
I see. I was introduced to apiman's codebase last week, so, it's just a
rookie's opinion here. Glad I could help and thanks for the fast feedbacks.
=)
On Tue, Jul 26, 2016 at 10:49 AM Eric Wittmann <eric.wittmann(a)redhat.com>
wrote:
OK thanks for the info - very helpful.
Regarding OK vs Apache - there is a design reason why OK is being used
vs. Apache that is perhaps not that interesting to get into. It has to
do with the way in which we stream the body of the request (and response).
I agree with the assessment of smart vs. dumb proxies - the apiman
gateway should definitely not be adding anything to the conversation
that wasn't configured via one of the policies. I definitely consider
this a bug, but I think it may require a fairly substantial rewrite of
the http connector to fix it. :( I'm not against doing it, but I was
hoping for a quick fix.
-Eric
On 7/26/2016 9:30 AM, Jairo Junior wrote:
> It results in a "415 Unsupported Media Type" at the endpoint, since it
> wasn't designed to consume application/x-www-form-urlencoded.
>
> I have experience with some ESB's, and, in most cases, when you have a
> proxy that is "too smart" it may break your endpoint behavior. And when
> we are talking about REST APIs, where we are using HTTP as both a
> transport and application protocol, any apiman interference may break
> behavior. It's OK for new APIs, but it's very bad for legacy.
>
> IMHO, if the gateway is deliberately including headers, there won't be
> any guarantees that the endpoint will be prepared for this. There is a
> general discussion in Microservices community regarding Smart Pipe X
> Dumb Pipe that is very relevant to what we are discussing here.
>
> Also, I thinkg okhttp is the best alternative when you're developing a
> client, but is it good to proxy requests? Have you considered Apache
> HTTP Client + PoolingHttpClientConnectionManager. It has some nice
> features like "per route" connection pooling that will probably be
> killing for a Gateway.
>
>
>
>
> On Tue, Jul 26, 2016 at 9:53 AM Eric Wittmann <eric.wittmann(a)redhat.com
> <mailto:eric.wittmann@redhat.com>> wrote:
>
> Question: what is the consequence of this problem?
>
> It turns out that fixing this issue may require fairly extensive
changes
> to how apiman proxies the request to the back end API. The
> http client[1] we are using for this is adding the content length and
> content type automatically for DELETE (as well as PUT and POST) if
they
> are missing. It's doing this because it claims the HTTP spec is
> ambiguous on whether DELETE can have a body.
>
> So how high a priority is this? Is it causing a specific problem for
> you, or is it simply something you noticed?
>
> -Eric
>
> [1] http://square.github.io/okhttp/
>
>
> On 7/25/2016 10:06 AM, Jairo Junior wrote:
> > Thanks again.
> >
> > On Mon, Jul 25, 2016 at 10:49 AM Eric Wittmann
> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com>
> > <mailto:eric.wittmann@redhat.com
> <mailto:eric.wittmann@redhat.com>>> wrote:
> >
> > JIRA issue created. In case you want to track it:
> >
> > https://issues.jboss.org/browse/APIMAN-1210
> >
> > -Eric
> >
> > On 7/25/2016 9:14 AM, Jairo Junior wrote:
> > > A client-side javascript app is performing the following
> request:
> > >
> > > /DELETE /apiman-gateway/org/service/1.1/resource/7 HTTP/1.1
> > > Host: 172.17.0.1:8080 <http://172.17.0.1:8080>
> <http://172.17.0.1:8080>
> > <http://172.17.0.1:8080>
> > > User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0)
> > > Gecko/20100101 Firefox/47.0
> > > Accept: application/json, text/plain, */*
> > > Accept-Language: en-US,en;q=0.5
> > > Accept-Encoding: gzip, deflate
> > > Authorization: Bearer $ACCESS_TOKEN
> > > Referer: http://172.17.0.1:3000/
> > > Origin: http://172.17.0.1:3000
> > > Connection: keep-alive
> > >
> > > /
> > > But the gateway is performing the following request to the
> endpoint:
> > >
> > > /DELETE /service/rest/resource/7 HTTP/1.1
> > > User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
> 5.1; SV1)
> > > Origin: http://172.17.0.1:3000
> > > Accept-Language: en-US,en;q=0.5
> > > Accept-Encoding: gzip, deflate
> > > Connection: keep-alive
> > > Authorization: Bearer $ACCESS_TOKEN
> > > Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> > > application/vnd.ms-excel, application/msword,
> > > application/vnd.ms-powerpoint, */*
> > > Referer: http://172.17.0.1:3000/
> > > Host: 172.17.0.1:8280 <http://172.17.0.1:8280>
> <http://172.17.0.1:8280>
> > <http://172.17.0.1:8280>
> > > Content-Type: application/x-www-form-//urlencoded
> > > Content-Length: 0
> > >
> > > /
> > > Resulting in a 415 Unsupported Media Type at the endpoint.
> > >
> > > GET, POST and PUT requests are OK.
> > >
> > > Only using CORS Policy for this endpoint:
> > >
> > > /Access-Control-Allow-Origin: *
> > > Access-Control-Allow-Credentials: true
> > > Access-Control-Allow-Headers: accept, authrotization,
> content-type
> > > Access-Control-Allow-Methods: GET, POST, PUT, DELETE
> > > Access-Control-Max-Age: 3600/
> > >
> > >
> > > _______________________________________________
> > > Apiman-user mailing list
> > > Apiman-user(a)lists.jboss.org
> <mailto:Apiman-user@lists.jboss.org>
> <mailto:Apiman-user@lists.jboss.org
> <mailto:Apiman-user@lists.jboss.org>>
> > > https://lists.jboss.org/mailman/listinfo/apiman-user
> > >
> >
>
2854
days inactive
2855
days old
6 comments
2 participants
participants (2)
-
Eric Wittmann -
Jairo Junior