Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Http.sys questions
#21
(01-27-2022, 12:21 PM)magosk Wrote: I have now focused a bit more on the shutdown problems (access violations etc.) I mentioned earlier (when running with http.sys rather than Indy). When I tested our main web application with IW 15.2.49 I saw no such problems, neither when run as a service nor when run as an application. But with our two other web applications I still had the issues when running as an application. As they share much code I tried to sort out the differences. I noticed that we had IWStartHSys (and previously IWStart) placed differently in the project uses clause. In the ones where I saw problems I had it pretty high up in the list of units, after IWJclDebug and IWJclStackTrace, whereas it was further down the list in the main web application. And when I move this unit down in the list, the shutdown problems seem to disappear. Do you have an explanation for this? Is it recommended to have the unit absolutely last in the uses list?

Best regards

Magnus Oskarsson

I'll run some tests and let you know. AVs shouldn't happen in either case
Reply
#22
(01-27-2022, 09:18 PM)Alexandre Machado Wrote:
(01-27-2022, 07:45 AM)magosk Wrote: Thanks for the explanation Alexandre!

(Yes, this was a sync call). Rather than removing it, I have modified my code so that it works with both older and newer versions of IntraWeb.

/Magnus

Can you please let me know how you changed it? It may be important for me to understand what your issue was

I just did this modification, so that the code would still work with IW 15.1 and prior, but do no change to the response in IW 15.2 when it is already a redirect (I guess the issue was that a duplicate Location header was created before):

Code:
procedure ChangeResponseCodeFromOKToRedirect(const URL: string);
begin
  if (WebApplication.Response.Code < 301) or (WebApplication.Response.Code > 303) then
    WebApplication.Response.Code := 302;
  if WebApplication.Response.Headers.IndexOfName('Location') < 0 then
    WebApplication.Response.AddHeader('Location', URL);
end{procedure};
Reply
#23
Hi again.

Just got an error report from tests of our web applications built with the latest IW version. I analyzed this and it was related to how URL parameters are interpreted. We have a parameter 'k' containing '+' characters which we read directly from WebApplication.RunParams.Values['k'] before (with IW 15.1.15) without problems, but now I get a string with '%2B' substrings instead of '+' (which is it's URL encoded form). So it seems like the (automatic) URL parameter decoding has changed from 15.1.15 to 15.2.49, can you confirm that? Fixing this particular case with e.g. a StringReplace is of course easy, but I would like to know if I should do any changes in the general case where URL parameters (potentially including encoded characters) are involved? (we use that in more places in the web applications)

/Magnus
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)