Opened 11 years ago

Closed 10 years ago

#3411 closed Bug (fixed)

Make HTTPS behave nicer when using stunnel

Reported by: bugmenot Owned by: charles
Priority: Normal Milestone: 2.02
Component: Daemon Version: 2.01
Severity: Normal Keywords: https http stunnel tunnel redirection web client ui patch-needed
Cc: bugmenot, zimnij@…

Description

hello, i am running web client + stunnel ( http://www.stunnel.org/ ) to have HTTPS enabled server, everything works just nice, whith following configuration:

[transmission] accept = 9092 connect = 9091

;transmission web client is running on port 9091 and HTTPS connections are accepted on 9092...

but for some reason, when i come to https://harvie.cz:9092/ i am asked for password and then redirected to http://harvie.cz:9092/transmission/web/ (note HTTP instead of HTTPS - such connection is naturaly refused) so i have to manually change http to https and then everything works just as expected. currently i have no big paint with it, because i've added https://harvie.cz:9092/transmission/web/ to my bookmarks, but i think it can be reasonable to handle it better (even when transmission itself is currently not able to use HTTPS, people will probably like to use stunnel with it...)

Change History (17)

comment:1 Changed 11 years ago by charles

  • Milestone 2.02 deleted
  • Severity changed from Major to Normal

Please stop setting milestones for tickets unless you've talked to one of the Transmission developers first. Do you think we don't have our own goals and timelines for releases?

comment:2 Changed 11 years ago by charles

Okay, I've just looked over the code and it looks like this is the relevant section:

        else if( !strcmp( req->uri, "/transmission/web" )
               || !strcmp( req->uri, "/transmission/clutch" )
               || !strcmp( req->uri, "/" ) )
        {
            const char * protocol = "http";
            const char * host = evhttp_find_header( req->input_headers, "Host" );
            const char * uri = "transmission/web/";
            char * location = tr_strdup_printf( "%s://%s/%s", protocol, host, uri );
            evhttp_add_header( req->output_headers, "Location", location );
            send_simple_response( req, HTTP_MOVEPERM, NULL );
            tr_free( location );
        }

It looks like maybe this is overkill -- the code could omit the protocol and server, and instead just use

            evhttp_add_header( req->output_headers, "Location", "/transmission/web/" );
            send_simple_response( req, HTTP_MOVEPERM, NULL );

instead. I've checked this into r10984 in trunk. Could you please try a nightly build, or make this change yourself locally, and let me know if it solves the issue for you?

comment:3 Changed 11 years ago by bugmenot

Sorry for milestones, thanks for fix :-) seems to be working for me :-) i thought that there were some more logic than was actually needed...

comment:4 Changed 11 years ago by charles

  • Milestone set to 2.02
  • Owner changed from kjg to charles
  • Status changed from new to assigned

Cool. That was surprisingly easy. :)

comment:5 Changed 11 years ago by charles

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed in trunk by r10984

Fixed in the 2.0x branch by r10985

comment:6 Changed 10 years ago by XenoPhoenix

This bug appears to still be present, at least for me in 2.22.

In interacts badly with the requires session id option as it requires several URL rewrites to connect successfully using https.

comment:7 Changed 10 years ago by livings124

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:8 Changed 10 years ago by jordan

  • Keywords patch-needed added

comment:9 Changed 10 years ago by zimniy

  • Cc zimnij@… added

comment:10 follow-up: Changed 10 years ago by jordan

I don't understand the current bug report. Does anyone have more information about what the issue is post-r10984?

comment:11 Changed 10 years ago by jordan

  • Resolution set to fixed
  • Status changed from reopened to closed

Re-closing this ticket due to lack of information.

Please reopen this ticket when more information is available.

comment:12 in reply to: ↑ 10 Changed 10 years ago by reardon

Replying to jordan:

I don't understand the current bug report. Does anyone have more information about what the issue is post-r10984?

It is still a problem, exactly as described in the original description. If you try to navigate to the naked url https://server:9092/ then the redirect fails. If you try initial connection to https://server:9092/transmission/web/ then all is well. The redirect does not maintain the https: prefix, if you will.

As far as I can tell, r10984 does nothing to alleviate.

comment:13 Changed 10 years ago by livings124

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:14 Changed 10 years ago by jordan

  • Component changed from Web Client to Daemon

comment:15 Changed 10 years ago by reardon

Ah, I think I finally fixed this due to the firefox7 problem.

A simple change to the relevant line in rpc-server.c

            char * location = tr_strdup_printf( "%sweb/", server->url );

I cannot see a reason to include the protocol+host prefix, as redirects are URIs, not URLs and thus are meant to be server-relative. Works now in firefox+chrome.

comment:16 Changed 10 years ago by livings124

Closing in favor of #4524.

comment:17 Changed 10 years ago by livings124

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.