Re: Is TIpClientHttp supposed to work for secured sites?
Posted: Tue Jul 28, 2020 11:22 pm
Yeah, I read something similar, but don't really see the use for it.
As it turns out, the web pages I'm trying to download are completely dynamic, so a direct download returns just html & js.
I'm trying to parse out about 3-4 fields, from an online Change record. There's nothing that Harbour can do about that, so I'll have to find another way. I checked with the Help Desk, and there's no API that can be used, either.
As it turns out, the web pages I'm trying to download are completely dynamic, so a direct download returns just html & js.
I'm trying to parse out about 3-4 fields, from an online Change record. There's nothing that Harbour can do about that, so I'll have to find another way. I checked with the Help Desk, and there's no API that can be used, either.
danielmaximiliano wrote: ↑Tue Jul 28, 2020 10:08 pmthis is what I found about answer 301HGAutomator wrote: ↑Tue Jul 28, 2020 8:00 pm Almost everything is working fine, except for trying to readall(), which returns nothing. The headers are returned, and they contain data. But that's a separate issue. The response code is a 301, so maybe I have to use a diferent url, after retriving it from another property of the TIpClientHttp class. Don't know, yet.
https://tools.ietf.org/html/rfc2616#section-9.210.3.2 301 Moved Permanently
The requested resource has been assigned a new permanent URI and any
future references to this resource SHOULD use one of the returned
URIs. Clients with link editing capabilities ought to automatically
re-link references to the Request-URI to one or more of the new
references returned by the server, where possible. This response is
cacheable unless indicated otherwise.
The new permanent URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s).
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.
Note: When automatically redirecting a POST request after
receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into a GET request.