Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File resource status shall be managed only for File mode answers #373

Open
dsauvage opened this issue Sep 30, 2023 · 4 comments
Open

File resource status shall be managed only for File mode answers #373

dsauvage opened this issue Sep 30, 2023 · 4 comments
Assignees
Labels

Comments

@dsauvage
Copy link

Description

As we can see in src/core/aws-server-http_utils.adb:1587

         File_Mode : constant Boolean :=
                       Response.Mode (Answer) in
                         Response.File .. Response.Stream;
         With_Body : constant Boolean := Messages.With_Body (Status_Code);
         File_Time : Ada.Calendar.Time;
         F_Status  : constant Resource_Status :=
                       Get_Resource_Status (C_Stat, Filename, File_Time);
         File      : Resources.File_Type;
      begin
         if F_Status in Up_To_Date .. Not_Found then
            if F_Status = Up_To_Date then
               --  [RFC 2616 - 10.3.5]
               Status_Code := Messages.S304;
            else
               --  File is not found on disk, returns now with 404
               Status_Code := Messages.S404;
            end if;

            Set_General_Header (Status_Code);

            Headers.Send_Header
              (Socket => Sock, Headers => H_List, End_Block => True);

            return;

File resource status is managed in all cases, even when Response.Mode (Answer) = Response.Message. This can happen in the following context;
Server A web service creates an answer using AWS.Response.File
Server B web service calls server A web service above using AWS.Client.Get and send back the response to the client

The patch below fix this issue by managing the file resource status only when the answer File_Mode is True, that is when Response.Mode (Answer) in Response.File .. Response.Stream. However shall we instead manage the file resource status for the File and File_Once modes only, keeping Stream mode out of it ?

         File_Mode : constant Boolean :=
                       Response.Mode (Answer) in
                         Response.File .. Response.Stream;
         With_Body : constant Boolean := Messages.With_Body (Status_Code);
         File_Time : Ada.Calendar.Time;
         F_Status  : constant Resource_Status :=
           (case File_Mode is
               when False => Changed,
               when True  => Get_Resource_Status (C_Stat, Filename, File_Time)
           );
         File      : Resources.File_Type;
begin
         if File_Mode and then F_Status in Up_To_Date .. Not_Found then
            if F_Status = Up_To_Date then

Patch
aws-server-http_utils.adb.patch.txt

@TurboGit
Copy link
Collaborator

TurboGit commented Dec 4, 2023

Thanks, this makes sense indeed.

@TurboGit TurboGit self-assigned this Dec 4, 2023
@TurboGit
Copy link
Collaborator

@dsauvage : It seems that this is already the case. If Filename = "" then Get_Resource_Status returns Changed, so I'm not sure this adds something. Right?

@dsauvage
Copy link
Author

No, it is not already the case. If on server A, AWS.Response.File is called with Disposition => AWS.Response.Attachment, then when server B will send the data, it will have File_Mode set to Message, and Filename set to non empty, thus leading to an HTTP 404 error status, as the Mode is Message and server B is erroneously checking for the existence of a file that does not exist on server B.
The proposed patch solve this bug.

@TurboGit
Copy link
Collaborator

@dsauvage : After a second analysis I agree with you. I have missed the case of attachments and so your patch is correct. Thanks.

@TurboGit TurboGit added the bug label Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants