Disable following redirects in httpGet call?

It appears that httpGet and its async versions will attempt to follow redirects. Is there a way to turn this behavior off via params? I need access to the headers of the redirect response itself rather than attempting to follow the redirect. Thanks.

-Chris

1 Like

I had the same question here.

I gave @chuck.schwer a potential solution I think. The groovy methods for GET, POST, PUT, etc. don't allow configuration to stop automatic redirect directly. However, I think each one has the ability to request the underlying http client which does have that functionality.

Anyway, I'm in the same boat. I need some cookies that were set in a redirect response. Alternatively I need a session so that cookies are stored from all responses and I don't have to do any of it manually. The Python session is handy. Not a lot of languages have a sweet, quick and easy session implementation though.

Just out of curiosity, what are you trying to do? I want to log into Comcast's internet usage page and scrape my internet usage for the month so I can display it as a RYG light in the kitchen. That way my wife can use it to slow the dang kids down on the Netflix usage if we're getting close to cap.

I HATE YOU, COMCAST. (I'm doing the middle finger to the air for emphasis.)

1 Like

@codahq I'm trying to retrieve the captured image from a motion camera in my Abode system, following the same approach that the abodepy Python library uses (abodepy/camera.py at master · MisterWil/abodepy · GitHub). Unfortunately, trying to automatically follow the redirect results in a 403 error from AWS due to an invalid signature (it redirects to an S3 bucket URL, and apparently the signature needs to exactly match headers, etc., which it doesn't). So what I really want is just the raw location header (i.e., the S3 URL) rather than being auto-redirected there.

Any update on this? It appears that it can be disabled in HttpBuilder (I get the impression that's what's being used) Any way to get it as another option on the httpGet call?

Bump. Is there someone at Hubitat I can tag to ask about this?

It hasn’t been added. I would suspect it’s not very high on the to do list.

I would also like to vote for this ehancement for all of the HTTP methods (and both sync & async). It seems like it would be a very easy enhancement for the dev team to make.

Here is the underlying three line code addition needed:
BasicHttpParams bhp = new BasicHttpParams()
bhp.setParameter('http.protocol.handle-redirects', false)
http.client.setParams(bhp)
hc apache org/httpcomponents-client-4.2.x/tutorial/html/httpagent.html

The behavior could be added as a standard param like this:
docs hubitat com/index.php?title=Common_Methods_Object#httpPost
followRedirects - possible values: true, false. If set to true, redirects will be followed, if false the system will not follow redirects. Defaults to true.

1 Like

It looks like only GET and HEAD need this parameter to NOT follow redirects. However, the converse logic TO follow redirects on POST (and the other verbs) could be useful for some developers. Mainly a documentation issue. Perhaps should disabled for the other verbs for security?

HTTP RFC 2616:
If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

1 Like

I have run in to this issue now in two different driver efforts, and it ended up being the brick wall at the end of the road for both unfortunately.

@gopher.ny or other Hubitat staff -- any chance you could expose options on the Hubitat Http APIs to disable and enable following redirects?

1 Like

Noted. I'll check how much that involves.

7 Likes

I'd like to chime in for support. Right now the MyQ community app is broken without this functionality added. Thanks!

Looks like added in 2.2.9!

  • Added HTTP request option followRedirects (boolean, default true).

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.