Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
IdHTTP corrections when proxy is used
#4
(05-06-2019, 12:11 PM)NevTon Wrote: Exactly, exception with content is buggy, there is no content inside exception object

It should be storing content in the exception object by default.  What SPECIFIC configuration are you using where the content is missing?  I need a CONCRETE EXAMPLE.

(05-06-2019, 12:11 PM)NevTon Wrote: (it seems that it is disregarded or something like it), and since there is exception, the easy way to check for "why", is to check response object, for example:

1. I do: http.Post(uri, input, output);
2. input contains some XML to be sended,
3. output is a TStringStream getting post return value,
4. Post is sended through PROXY,
5. If proxy needs authentication, it responds with error 407 - authentication required and some HTML page describing the reason,
(this is special situation - because this is exception and valid response at the same time, it should be fully parsed)
6. I need to catch exception and to be able to check: http.Response.ContentType = "text/html",
7. in fact, I need all http.Response object filelds to be filled with what was the response from proxy as it was normal (good) response.

The TIdHTTP.Response object is ALWAYS populated with data from the response headers before EIdHTTPProtocolException is raised.  The only thing that is handled separately is where the response body data, if anywhere.

TIdHTTP raises EIdHTTPProtocolException on a 407 reply from a proxy (subject to hoNoProtocolErrorException and AIgnoreReplies) only if either:
  • no TIdAuthentication class type is selected based on the proxy's 'Proxy-Authenticate' response header, because the appropriate TIdAuthentication classes are not registered (you need to add the relevant units to your uses clause), and/or the user's TIdHTTP.OnSelectProxyAuthorization event handler (if assigned) returns nil.
  • the user's TIdHTTP.OnProxyAuthorization event handler (if assigned) returns False.
  • authorization fails too many times in a row (TIdHTTP.AuthProxyRetries exceeds TIdHTTP.MaxAuthRetries).

If EIdHTTPProtocolException is raised, the response body data SHOULD be stored in the exception object by default.  So, what are you doing SPECIFICALLY to cause it NOT to be stored in the exception object?

(05-06-2019, 12:11 PM)NevTon Wrote: Remy, can You see what is the problem here?

No, I don't. You need to walk me through a SPECIFIC scenario, with SPECIFIC examples.

(05-06-2019, 12:11 PM)NevTon Wrote: 1. If I catch exception, there is two things that interest me: exception code (407) and reason (authentication required message) - it is the first line of every response raw header,

Those 2 values are ALWAYS stored in the EIdHTTPProtocolException object, in its ErrorCode and Message properties, respectively.

Those same 2 values are ALWAYS available in the TIdHTTP.Response object as well, in its ResponseCode and ResponseText properties, respectively.

(05-06-2019, 12:11 PM)NevTon Wrote: 2. this and other details should be also contained in http.Response object fields - where is its place.

ALL of the HTTP response headers are ALWAYS stored in the TIdHTTP.Response object, in its RawHeaders property, as well as individual sub-properties for individual headers that TIdHTTP parses for you.

There is nowhere available in the TIdHTTP.Response object for the HTTP response body data to be stored.  So, it MAY be stored in an EIdHTTPProtocolException object (in its ErrorMessage property), or it MAY be stored in the user's target TStream, or it MAY be discarded, depending on the HTTP error state and how the TIdHTTP.HTTPOptions flags are configured.  This is BY DESIGN, whether you agree with the design or not.

(05-06-2019, 12:11 PM)NevTon Wrote: But You constantly saying that Indy 11 will be rebuild and better, why not start to getting there already?

Everything that I have previously mentioned that I wanted for Indy 11 has been pushed back to Indy 12.  Indy 11 (if it ever gets released at this point) has been decided to be just a maintenance release to clean up the existing codebase (drop support for old compilers, cleanup IFDEFs, tweak the packages to utilize {$LIBSUFFIX}, streamline installation steps, etc).  No new component features, no code redesigns, just cleanup (and MAYBE get it into Embarcadero's GetIt component manager, finally).  Work has already been done on this effort (see the "Restructure" branch in Indy's SVN and GitHub repositories), but it is not quite finished yet (the packages still need to be updated and tested).

Reply


Messages In This Thread
IdHTTP corrections when proxy is used - by NevTon - 04-29-2019, 01:17 PM
RE: IdHTTP corrections when proxy is used - by rlebeau - 05-07-2019, 07:00 PM

Forum Jump:


Users browsing this thread: 2 Guest(s)