GAE std with java8 making https request

105 views
Skip to first unread message

Robert Dyas

unread,
Jul 13, 2017, 11:40:28 AM7/13/17
to Google App Engine
We have GAE std app that has been running for a coupe of years on java7 making some https requests out to our credit card processor. Works fine.

When we switched to java8 runtime those same https requests are getting a 400 response code from the credit card processor.

Any ideas as to what might be causing this or where to look?

Robert Dyas

unread,
Jul 13, 2017, 3:07:20 PM7/13/17
to Google App Engine
On further research it is something to do with native vs urlfetch:

<url-stream-handler>urlfetch</url-stream-handler>

Adding the above to my appengine-web.xml file allows it to run correctly in both java7 and java8 (would be nice to have this mentioned in the notes about switching to java8 from java7... and a summary of any other compatibility settings).

Now the remaining question is: why when using native does it not work?

Yannick (Cloud Platform Support)

unread,
Jul 13, 2017, 4:55:09 PM7/13/17
to Google App Engine
Hello Robert,

Have you tried logging your requests (with headers) to check in which ways they differ? There might be some platform-specific differences that the card processor is not accounting for or handling poorly for some reason.

Robert Dyas

unread,
Jul 14, 2017, 11:07:49 AM7/14/17
to Google App Engine
I don't know of any way to log the outbound headers, but yes I've logged and sent the card processor the response headers.
I assume app engine urlfetch adds some headers on outbound but I can't see how that would matter.
Stumped. Waiting for their reply after they look into it.

Can I assume that outbound https with java8 native is "unmolested" or does google still intercept requests and responses?

Yannick (Cloud Platform Support)

unread,
Jul 14, 2017, 11:50:59 AM7/14/17
to google-a...@googlegroups.com
Is it possible for you to test if this issue also occurs on the local development server? If so you could simply use Wireshark to capture outbond requests from your app and see for yourself how they differ using different libraries. If it turns out that they are malformed you should report the bug on our Issue Trackers with as much reproduction information as possible so that we may address the issue.

Our documentation explains the behavior of the urk-stream-handler parameter here and here. According to these pages the native stream handler uses the Java runtime and should not go through UrlFetch.
Reply all
Reply to author
Forward
0 new messages