Opened 7 years ago

Closed 6 years ago

#13696 closed bug (fixed)

[WebPositive] https redirects seems to be broken

Reported by: diver Owned by: pulkomandy
Priority: normal Milestone: Unscheduled
Component: Applications/WebPositive Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #13756
Platform: x86-64

Description (last modified by diver)

hrev51365 x86_64

WebPositive http://ya.ru doesn't work while https://ya.ru works same with google.ru - http doesn't work However both http://google.com and https://google.com don't load at all.

Change History (19)

comment:1 by pulkomandy, 6 years ago

It would be interesting to build libbnetapi in debug mode and use that to get some logs for network events. However I fear it would make the issue disapear.

comment:2 by korli, 6 years ago

Platform: Allx86-64

comment:3 by diver, 6 years ago

Description: modified (diff)

comment:4 by diver, 6 years ago

Indeed, building libnetapi in debug mode by adding in build/jam/UserBuildConfig

HAIKU_BUILD_FEATURE_SSL = 1 ;
SetConfigVar DEBUG : HAIKU_TOP src kits network libnetapi : 1 : global ;

and running:

LD_PRELOAD=/data/haiku/generated/objects/haiku/x86_64/debug_1/kits/network/libnetapi/ssl/libbnetapi.so WebPositive http://ya.ru

makes this problem go away...

comment:5 by pulkomandy, 6 years ago

The problem also happens (but less frequently) on x86. It is timing/scheduling related.

The code for redirects in Web+ is quite messy, and does not use the libnetapi handling because the browser needs to be aware of redirections to update the "current" URL. When a redirect happens, the WebKit code will immediately delete the HTTP request and create a new one for the new URL. However, all messages queued by the original request (as BMessages to the WebKit main app) will still be processed. The code tries to detect and ignore these, but it doesn't work reliably.

My guess is that it interprets the "end of request" from the previous request and ends the second one because of it. When debug is enabled, the logging changes the timing and the problem doesn't happen.

Last edited 6 years ago by pulkomandy (previous) (diff)

in reply to:  5 comment:6 by korli, 6 years ago

Replying to PulkoMandy:

The problem also happens (but less frequently) on x86. It is timing/scheduling related.

If so, then it's a duplicate of #13642?

comment:7 by pulkomandy, 6 years ago

Probably, but it's hard to tell if it's exactly the same problem without any logs.

comment:8 by diver, 6 years ago

I *think* Web+ still worked for me when 13642 was created. It might be the same issue in the end. What kind of logs are needed? Do I need to open a page with debug build of libnetapi that doesn't open otherwise and attach stdout log?

comment:9 by korli, 6 years ago

I built libbnetapi with DEBUG=1 (in SubDirC++Flags) and launched WebPositive on http://www.free.fr, a pop up with "The URL cannot be shown" is displayed.

    HTTP: Resolving http://www.free.fr/
    HTTP: Hostname resolved to: 212.27.48.10:80
    HTTP: Connection to www.free.fr on port 80.
    HTTP: Connection opened, sending request.
--> HTTP: Host: www.free.fr
--> HTTP: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
--> HTTP: Accept-Encoding: gzip
--> HTTP: Connection: close
--> HTTP: User-Agent: Mozilla/5.0 (Macintosh; Intel Haiku R1 x86) AppleWebKit/602.1.26 (KHTML, like Gecko) WebPositive/1.2 Version/9.2 Safari/602.1.26
    HTTP: Request sent.
    HTTP: Status line received: Code 302 (Moved Temporarily)
<-- HTTP: Server: nginx
<-- HTTP: Date: Thu, 26 Oct 2017 15:09:22 GMT
<-- HTTP: Content-Type: text/html
<-- HTTP: Content-Length: 154
<-- HTTP: Connection: close
<-- HTTP: Location: http://www.free.fr/freebox/index.html

Dunno if that helps.

comment:11 by korli, 6 years ago

Hey Adrien, thanks, I'm away for a few days, won't be able to test until next week.

comment:12 by pulkomandy, 6 years ago

There is another problem left, apparently a memory corruption. I'm trying to understand what happens, eventually it seems I get a BHttpHeader where the fName Bstring ends up pointing to freed memory for its fPrivateData. But I don't see a scenario which would lead to that. It happens betweenTrim and CapitalizeEachWord in the SetName method. At that point the BString is accessed only from one thread and it was just set to a new data buffer initialized with the name.

Possibly a bug in BString or we are misusing the API here.

comment:13 by korli, 6 years ago

Hi Adrien! The patch is not enough, the problem stays the same.

It seems the relevant code showing the popup was introduced in https://github.com/haiku/webkit/commit/95db3d3d08d3e64072caca4ef38c3c54152e697d. Which means that a valid base URL is required on a redirect. A URL object only becomes valid when parsing a URL string.

I changed the used URL constructor in KURLHaiku.cpp and the behavior described in this bug is then fixed. This is basically a revert of the first part of https://github.com/haiku/webkit/commit/4d26e350bbbf2502d00657a1d8c73e5e81018bb5

   parse(String.fromUTF8(url.UrlString()));

comment:14 by pulkomandy, 6 years ago

Sounds right, this constructor would lead to a partially uninitialized object (m_protocolIsInHttpFamily would not be set either, for example). No way to avoid re-parsing the URL from a string here, it seems. And I'm not sure the URL string would properly be allocated and generated, which may explain other problems as well.

comment:15 by korli, 6 years ago

Patched in 1.6.2-3. Updated in hrev51515 for x86_64.

comment:16 by diver, 6 years ago

Thanks, korli! Everything seems to be working fine now :)

comment:17 by pulkomandy, 6 years ago

Blocking: 13756 added

comment:18 by korli, 6 years ago

This should already be fixed, or not?

comment:19 by pulkomandy, 6 years ago

Resolution: fixed
Status: newclosed

Yes, changes were integrated in HaikuWebKit 1.6.3.

Note: See TracTickets for help on using tickets.