HttpMessage debugging request

[mtravis-interpretive]

This is a feature request so feel free to say no, and we will just adopt a policy where people will have to manually configure connections if the dynamic URLs fail to work.

We are running into cases every 2-3 weeks where we have University staff try to automatically register using a dynamic URL which triggers a sendRegistration request to their LMS, and the LMS rejects it for one reason or another. This behavior is not restricted to a particular LMS. In most cases, it works fine, but for those Universities that run into problems, they end up having to manually configure a platform connection in our system to connect which is a lot to ask for the average end user. The only message returned by the request is "Unable to register with platform", but we've found that the LMSs often have more detail in their responses to the HttpMessage send() than that when we temporarily enable error logging in the Tool.

Would it be possible for you to add a static property to the HttpMessage class that tracks the last message generated from send calls?

Right now, you have that behind a Util::$logLevel->logError() check. Ideally, we want to leave debugging off in our production environment because logging information for every call would just fill up the logs. We only want to check the message if an error was encountered. With a static property, we could check if the last call was !$this->ok and then access the HttpMessage static property for the last message from our code that calls sendRegistration and do some parsing to identify the true cause of the rejection for the users. This would save a lot of confusion for both the University staff and our staff.

With a static property, you could always generate the message and populate the static property. Then if logging is enabled, you could do the final step and output it to the log from the static property. For example, something like this:

self::$last_message = "Http\\HttpMessage->send {$this->method} request to '{$this->url}'";
if (!empty($this->requestHeaders)) {
     self::$last_message .= "\n" . implode("\n", $this->requestHeaders);
}
if (!empty($this->request)) {
     self::$last_message .= "\n\n{$this->request}";
}
self::$last_message .= "\nResponse:";
if (!empty($this->responseHeaders)) {
      self::$last_message .= "\n\nHeaders:" . implode("\n", $this->responseHeaders);
}
if (!empty($this->response)) {
      self::$last_message .= "\n\nBody: {$this->response}";
}
if (!empty($this->error)) {
      self::$last_message .= "\nError: {$this->error}";
}
               
if (Util::$logLevel->logError()) {
      if ($this->ok) {
             Util::logInfo(self::$last_message);
      } else {
              Util::logError(self::$last_message);
      }
}

Thank you for considering our request.

[spvickers]

Thanks for the suggestion, but perhaps you can provide a little more clarification.

I completely understand the desire to keep the size of log files down, but if you are wanting errors to be logged what is wrong with setting the log level to "error"? The debug level of logging would certainly overflow your log files, but the error level should only be logging when a error occurs.

In addition, the HttpMessage class has attributes giving access to the response body and response headers - can you not use these?

[mtravis-interpretive]

We have a wrapper for the Tool class that allows us to do a call like this (using the default sendRegistration function). We chose to do it this way in case you make changes to the function in the future.

$registrationConfig = $this->sendRegistration($platformConfig, $toolConfig);

Then, the Tool class sendRegistration function instantiates an instance of the HttpMessage class. Because the instance of the HttpMessage class is local to the sendRegistration function, we don't have access to it's properties when we call it from our wrapping code.

The reason for not wanting to write to the error log is that we want to access the data in real time without parsing our logs to get the error. This is because as soon as the registration fails, we display an error message to the user letting them know it failed. If we had that additional information from the request, we could also tell the user the specific reason why the request failed.

Right now, the user sees something like this as soon as the request fails.

[spvickers]

Thanks for the clarifications. I can see that this could be resolved by having a static variable for the last instance of an HttpMessage. An alternative would be to make the instance used by the sendRegistration method visible to the Tool class instance. I'll check if there are any other service requests where this issue might apply before making a proposal for a solution,