Project

General

Profile

Bug #7965

Excessively severe log message: "Unexpected GET request with wtd of existing Ajax session" -- in some cases

Added by Bruce Toll almost 2 years ago. Updated 12 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
01/10/2021
Due date:
% Done:

100%

Estimated time:

Description

Versions of Wt since 4.4.0 can log a "[secure]" level message of "Wt: Unexpected GET request with wtd of existing Ajax session" for situations that do not represent a security concern.
This "Unexpected GET request" message can occur in bootstrap mode with Wt version 4.5.0-rc1-10-g802b86cd in at least two cases after the transition to ajax has occurred:

  1. Chromium-based browsers may re-send the "request=style" GET request the first time that the Developer Tools window is opened for a page. This results in a reply with 403 status and logs an "Unexpected GET request with wtd of existing Ajax session" message.
  2. When Javascript is available on the client, there are two requests that arrive in an unspecified order: the script and the style requests. The style request typically arrives first, but when the script request arrives first, the session will transition to Ajax mode before the style request arrives. Functionally, this is acceptable because the stylesheets are added to the DOM via Javascript and the style request is not needed. However, the "Unexpected GET request with wtd of existing Ajax session" message is logged and a reply with 403 status is sent.

The impact of returning a 403 status seems to be harmless in both of the above cases, but the log message makes it sound like a potentially serious event.

Attached, for your review, is a lightly tested patch that permits style requests to be processed after ajax mode as been initiated. There is more information in the commit message for the patch.
NOTE: There are other style requests (observed in logs) where the 403 status and message did seem appropriate, e.g. different IP address. Applying the patch will restore pre-4.4.0 behavior for these, as well.

NOTE on Testing: Case 1 should hopefully be easy to reproduce. For case 2, I used mitmproxy 4.0.4 to delay the style request. With a test app running on port 8080 and an mitmproxy command similar to:

mitmproxy --intercept '~u request=style & ~q' -p 8090 -m reverse:http://localhost:8080

Browse to http://localhost:8090 and after a few seconds, press 'A' in the mitmproxy session to allow the intercepted style request to continue.


Files

#1

Updated by Roel Standaert almost 2 years ago

  • Target version set to 4.5.1
#2

Updated by Roel Standaert over 1 year ago

  • Assignee set to Korneel Dumon

Can you take a look at this, Korneel?

#3

Updated by Roel Standaert over 1 year ago

  • Assignee deleted (Korneel Dumon)
  • Target version changed from 4.5.1 to 4.7.0

In the interest of getting the next release out as soon as possible, I'm moving the target version for this issue.

I'm also unassigning Korneel, we'll see who ends up picking this up.

#4

Updated by Korneel Dumon over 1 year ago

  • Status changed from New to InProgress
  • Assignee set to Korneel Dumon
  • Target version changed from 4.7.0 to 4.6.0
#5

Updated by Korneel Dumon over 1 year ago

  • Target version changed from 4.6.0 to 4.7.0
#6

Updated by Korneel Dumon over 1 year ago

  • Status changed from InProgress to Review
#7

Updated by Roel Standaert about 1 year ago

  • Status changed from Review to Implemented @Emweb
  • Target version changed from 4.7.0 to 4.6.0

Ok, since 4.6.0 was taking so long this did end up in 4.6.0.

#8

Updated by Roel Standaert about 1 year ago

  • % Done changed from 0 to 100
#9

Updated by Roel Standaert about 1 year ago

  • Status changed from Implemented @Emweb to Resolved
#10

Updated by Roel Standaert 12 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF