5

In the Google App Engine standard environment, if you use urllib to make HTTPS requests, you'll get an AppEnginePlatformWarning which says you're using urlfetch instead of sockets.

I found the warning annoying, so I disabled it.

# Use the App Engine Requests adapter. This makes sure that Requests uses
# URLFetch.
requests_toolbelt.adapters.appengine.monkeypatch()

# squelch warning
requests.packages.urllib3.disable_warnings(
    requests.packages.urllib3.contrib.appengine.AppEnginePlatformWarning
)

My question is - is there a good reason to switch to sockets? Specifically what is wrong with using urlfetch?

JamesHutchison
  • 885
  • 2
  • 8
  • 17

1 Answers1

3

There's nothing wrong with using urlfetch, in fact it is the recommended method for issuing outbound HTTP(S) requests on GAE. From Issuing HTTP(S) Requests (emphasis on requests-related note mine):

App Engine uses the URL Fetch service to issue outbound HTTP(S) requests.

For details about how the URL Fetch service is implemented and which headers are sent in a URL Fetch request, see Outbound Requests.

Issuing an HTTP request

To issue an outbound HTTP request, use the urlfetch.fetch method. For improved code portability, you can also use the Python standard libraries urllib, urllib2, or httplib to issue HTTP requests. When you use these libraries in App Engine, they perform HTTP requests using App Engine's URL Fetch service. You can also use the third-party requests library as long as you configure it to use URLFetch.

The sockets support is rather the problematic one in GAE, it comes with a fairly long list of limitations and restrictions, see Sockets Python API Overview, in particular the Limitations and restrictions section.

The warning you see is not from GAE, it's from the 3rd-party requests library you use, which is why I highlighted the note in the above quote. IMHO it's safe to simply ignore/mask the warning in a GAE context.

Dan Cornilescu
  • 39,470
  • 12
  • 57
  • 97
  • The warning was made explicitly for App Engine, which is what is confusing. It's actually coming from urllib3, not requests. Requests simply packages it within itself. – JamesHutchison Nov 27 '17 at 05:58