4

I've been working on this issue for days. I'm a developer and my knowledge of these things is very limited, still there's no one available in this company to assist me with this issue. This really has to get resolved, as it's getting a blocking issue.

We are running an AS/400 with an Apache installation to deploy REST services. I don't know many technical details, but the information reports "Apache server <servername> - Apache/2.4.2 (IBM i)".

The problem is CORS: when using a PUT/DELETE, a preflight OPTIONS request is send to the server. The response returns a 200 OK, but doesn't return a CORS header like Access-Control-Allow-Origin *. Because of this (I assume) the real request isn't executed and the browser returns a CORS error:

No 'Access-Control-Allow-Origin' header is present on the requested resource.

The web services are configured to return this header, but it's not possible to returns this for an OPTIONS request.

I've tried to configure Apache so it always returns this header, but it doesn't work. No matter which header I add, it's not being returned to the browser.

My httpd.conf:

LoadModule mod_ibm_lwi /QSYS.LIB/QHTTPSVR.LIB/QLWIIHSMOD.SRVPGM
HotBackup Off
KeepAlive Off
DocumentRoot /www/WS_REST_BE/htdocs
AddLanguage en .en
LogMaint logs/error_log 7 0
LogFormat "%h %T %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
Listen *:10043
<Location />
  AllowOverride All
  Require all granted
Header set Access-Control-Allow-Origin "*"
</Location>
LoadModule was_ap20_module /QSYS.LIB/QHTTPSVR.LIB/QSVTAP24.SRVPGM
WebSpherePluginConfig /www/WS_REST_BE/conf/ias-plugin-cfg.xml
<LwiProfile WS_REST_BE>
  LwiAssignUserID WEBSBEPRD
  LwiAutostartOption StartEnd
  LwiStartJobQueue QHTTPSVR/QZHBHTTP HTTPWWW
</LwiProfile>
AddCharset UTF-8 .html .js
AddDefaultCharset utf-8

I've already tried to set the header at different places in the config, but it just doesn't work. The IBM documentation clearly says mod_headers is supported (and it should be enabled).

I hope someone here can guide me to the right direction to solve this problem.

Note: if I need to supply more information, feel free to ask!

Bv202
  • 91
  • 5
  • 1) Did you restart the HTTP server after changing httpd.conf? 2) Does the error log have anything to say? 3) What version of IBM i are you running, and are you current on PTFs? – Buck Calabro Jul 20 '15 at 15:09
  • 1) Yes, I did multple times. 2) No, nothing 3) v7 release 1 and no PTF. – Bv202 Jul 22 '15 at 06:59

2 Answers2

0

OK, this is a guess, but:

You have your Header directive inside of <Location /> ... </Location>. When the client sends a preflight request, it uses the HTTP OPTIONS method. Since OPTIONS doesn't request any particular resource, the Location directive may not be getting activated.

Try moving your Header directive outside of the Location.

Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
0

I develop REST services myself, but I implemented the CORS headers onto the response with interceptors in JavaEE. Your error message states

No 'Access-Control-Allow-Origin' header is present on the requested resource.

, which references to the POST/DELETE request afaik. Try to add the CORS headers to the POST/DELETE answers.

See as reference: http://www.developerscrappad.com/1781/java/java-ee/rest-jax-rs/java-ee-7-jax-rs-2-0-cors-on-rest-how-to-make-rest-apis-accessible-from-a-different-domain

As far as I understand, Apache should not be the problem, but the REST services. See also: https://en.wikipedia.org/wiki/Cross-origin_resource_sharing#How_CORS_works

Rick-Rainer Ludwig
  • 123
  • 1
  • 8
  • Thanks, but the services are written in RPG, not Java and it's not possible to handle OPTIONS requests.. – Bv202 Jul 23 '15 at 09:19
  • Java was only the example for the CORS headers which are to be put into the response header of PUT/DELETE and so forth. Did you try to put the CORS headers there? I do not know RPG, so I cannot help with that unfortunatelly. Can you check whether the service reacts with the request mentioned above? If it does, you see the request reaches the service. As far as I understand it (and what I do in my services), I put the CORS header into the header of the response sent back to browser. The CORS headers are checked by the browser and not by the server. – Rick-Rainer Ludwig Jul 23 '15 at 19:33
  • Yup, the server returns these when doing a PUT/DELETE. I can confirm that with Postman. But they are not returned when the browser does an OPTIONS, which is done before doing the actual PUT/DELETE. – Bv202 Jul 24 '15 at 06:05
  • OK, in that case I cannot help further. I know that this OPTIONS stuff happens before, but I do not have detailed knowledge about that and I didn't need to take about it so far. – Rick-Rainer Ludwig Jul 24 '15 at 19:28