https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 --- Comment #1 from David Cook <dcook@prosentient.com.au> --- Also, if you have a reverse proxy in front of Apache and you proxy using HTTP rather than HTTPS, Apache will generate fully qualified HTTP URLs for the Redirect, which cause one of the two scenarios: Scenario 1: 1) Client (C) requests HTTPS from Reverse Proxy (RP) 2) RP requests HTTP from Apache (A) 3) A sends HTTP redirect to RP 4) RP sends HTTP redirect to C 5) C requests HTTP from RP Now you've just downgraded your HTTPS to HTTP by accident Scenario 2 (Force HTTPS): 1) Client (C) requests HTTPS from Reverse Proxy (RP) 2) RP requests HTTP from Apache (A) 3) A sends HTTP redirect to RP 4) RP sends HTTP redirect to C 5) C requests HTTP to RP 6) RP sends HTTPS redirect to C Now you've just redirected twice bouncing from HTTPS to HTTP to HTTPS for just 1 search. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 --- Comment #2 from David Cook <dcook@prosentient.com.au> --- Created attachment 105136 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=105136&action=edit Bug 25548: Remove Apache rewrite directives that trigger redirects Historically, we have used Apache rewrite directives to strip query parameters with no arguments from the query string (e.g. PARAM=&), and then redirect to the new URL. However, this slows down user activity, and depending on your HTTPS and proxy setup can cause suboptimal HTTP downgrades and upgrades. Test Plan: 0) Apply patch 1) Build Debian package 2) Install Debian package and reload Apache 3) Open developer tools on your favourite browser 4) Go to Network tab in developer tools 5) Go to /cgi-bin/koha/opac-main.pl 6) Search for "test" 7) Note a 200 status for "opac-search.pl?idx=&q=test" If you got a 302 status for "opac-search.pl?idx=&q=test" followed by a 200 status for "opac-search.pl?q=test", you will know that your Apache configuration wasn't updated. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 Fridolin SOMERS <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=7607 CC| |fridolin.somers@biblibre.co | |m --- Comment #3 from Fridolin SOMERS <fridolin.somers@biblibre.com> --- Ah and it causes Bug 7607 +1 to remove useless rewrites. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 Fridolin SOMERS <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 Fridolin SOMERS <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #105136|0 |1 is obsolete| | --- Comment #6 from Fridolin SOMERS <fridolin.somers@biblibre.com> --- Created attachment 110985 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=110985&action=edit Bug 25548: Remove Apache rewrite directives that trigger redirects Historically, we have used Apache rewrite directives to strip query parameters with no arguments from the query string (e.g. PARAM=&), and then redirect to the new URL. However, this slows down user activity, and depending on your HTTPS and proxy setup can cause suboptimal HTTP downgrades and upgrades. Test Plan: 0) Apply patch 1) Build Debian package 2) Install Debian package and reload Apache 3) Open developer tools on your favourite browser 4) Go to Network tab in developer tools 5) Go to /cgi-bin/koha/opac-main.pl 6) Search for "test" 7) Note a 200 status for "opac-search.pl?idx=&q=test" If you got a 302 status for "opac-search.pl?idx=&q=test" followed by a 200 status for "opac-search.pl?q=test", you will know that your Apache configuration wasn't updated. Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 --- Comment #8 from Fridolin SOMERS <fridolin.somers@biblibre.com> --- (In reply to Katrin Fischer from comment #4)

Frido, maybe a sign-off then? :)

Allez ;) Tested on Strech with Koha 20.05 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 --- Comment #10 from David Cook <dcook@prosentient.com.au> --- (In reply to Fridolin SOMERS from comment #9)

Looks like this rewite is disabled in koha-httpd.conf since Koha 3.12 ^^

I think that you and I were the ones who did that one back in the day! Heh. And thanks for the sign off and follow-up! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #110986|0 |1 is obsolete| | --- Comment #12 from Julian Maurice <julian.maurice@biblibre.com> --- Created attachment 111063 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=111063&action=edit Bug 25548: (follow-up) Remove those rewrite redirects in koha-httpd.conf In etc/koha-httpd.conf for dev install, those rewrite redirects are already commented. Just remove them. Signed-off-by: Julian Maurice <julian.maurice@biblibre.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl --- Comment #13 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Looks good to me too. But a rather intriguing question is: is there some script somewhere that depended somehow on the logic of removed empty parameters? (Apart from seeing the other way around on the see also bug.) Have the impression that David already had this in production for longer, so it is probably highly fictitious ;) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@bugs.koha-c | |ommunity.org, | |nick@bywatersolutions.com, | |tomascohen@gmail.com Depends on| |18669 Status|Passed QA |In Discussion --- Comment #15 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Hum, funny how this one and bug 7607 end up PQA at the same time. I won't push both as this one will fix the problem from bug 7607. (In reply to David Cook from comment #0)

It means that every simple search to /cgi-bin/koha/opac-search.pl from the masthead will redirect from /cgi-bin/koha/opac-search.pl?idx=&q=blah to /cgi-bin/koha/opac-search.pl?q=blah.

It's OK if we have idx= in the URL.

However this is not only having ONE idx=, an adv search will become /cgi-bin/koha/catalogue/search.pl?advsearch=1&idx=kw&q=ti&idx=kw&q=&idx=kw&q=&limit=&limit=&limit=&limit=&limit=&sort_by=relevance That's starting to be ugly. was: /cgi-bin/koha/catalogue/search.pl?advsearch=1&idx=kw&q=ti&idx=kw&idx=kw&sort_by=relevance This has been an historical behaviour, how can we know it won't impact people? At the minimum we should comment them I'd say. Tomas, Nick, what are your thoughts on this one? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18669 [Bug 18669] RewriteCond affecting wrong rule in koha-httpd.conf -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 --- Comment #17 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> ---

I dont understand it. You say here that the number of empty parameters increases?

OK Sleeping :) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 --- Comment #19 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Marcel de Rooy from comment #18)

(In reply to Jonathan Druart from comment #15)

...

/cgi-bin/koha/catalogue/search. pl?advsearch=1&idx=kw&q=ti&idx=kw&q=&idx=kw&q=&limit=&limit=&limit=&limit=&li mit=&sort_by=relevance

That's starting to be ugly.

I agree that it is ugly. But does it really matter the user?

We show the lines in search history and other places... and users are sharing them on social media, in emails etc. I also think they are much less readable/guessable for users. I'd much prefer the shorter links. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 --- Comment #21 from David Cook <dcook@prosentient.com.au> --- (In reply to Nick Clemens from comment #20)

Would it be reasonable to clear empty inputs with javascript before the submission?

I like your thinking here, Nick. It would be better to prevent creating ugly query strings rather than trying to fix them after the fact. Plus, in a future where we may just use Starman/Hypnotoad to serve Koha, we won't be able on Apache URL rewriting trickery. So maybe Javascript to clear empty inputs with Javascript, or Javascript to build the request. The former would probably be easier to bolt on to the status quo. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 --- Comment #23 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Jonathan Druart from comment #22)

Who is volunteering?

Hm, just clearning the inputs won't fix the problem of bug 7607 I think? The problem is, that people leave search fields empty so idx and search terms don't match up. kw - no search term entered title - some title words Turns into: kw search for some title words We have found this workaround from the other bug to be working, but I am not sure if that will fix the ugliness of the URL. $(document).ready(function(){ $("input[name='do']").click(function(){ $("input[name='q']").each(function(i){ if (!$(this).val()){ $("select[name='idx']").eq(i).append('<option value="" selected="selected"></option>'); } }); }); }); and in intranetuserjs : $(document).ready(function() { $("#submit1,#submit2").click(function(){ $("input[name='q']").each(function(i){ if (!$(this).val()){ $("select[name='idx']").eq(i).append('<option value="" selected="selected"></option>'); } }); }); }); -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 --- Comment #24 from David Cook <dcook@prosentient.com.au> --- (In reply to Nick Clemens from comment #20)

Would it be reasonable to clear empty inputs with javascript before the submission?

On reflection, that won't work the way you think it would work. It would create the problems described in Bug 7607. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 --- Comment #26 from David Cook <dcook@prosentient.com.au> --- I am tempted to move this back to "Passed QA" because it actually resolves the problem from Bug 7607. While it makes for uglier URLs, it is functionally superior. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |In Discussion --- Comment #27 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- (In reply to David Cook from comment #24)

(In reply to Nick Clemens from comment #20)

...

Would it be reasonable to clear empty inputs with javascript before the submission?

On reflection, that won't work the way you think it would work. It would create the problems described in Bug 7607.

It won't if you remove the related idx. I don't think we should push this patch without having both sides happy. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 --- Comment #29 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #27)

I don't think we should push this patch without having both sides happy.

David Nind and I have signed off on Nick's patch on Bug 7607. Once QA pass it, then we should all be happy ^_^. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |20.11.00 released in| | Status|Passed QA |Pushed to master -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to master |Pushed to stable CC| |andrew@bywatersolutions.com Version(s)|20.11.00 |20.11.00, 20.05.07 released in| | --- Comment #32 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Pushed to 20.05.x for 20.05.07 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 Bug 25548 depends on bug 7607, which changed state. Bug 7607 Summary: Advanced search: Index and search term don't match when leaving fields empty https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7607 What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to oldstable |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 --- Comment #34 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Victor Grousset/tuxayo from comment #33)

Not backported to oldoldstable (19.11.x). Feel free to ask if it's needed.

It is needed! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 Agustín Moyano <agustinmoyano@theke.io> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |agustinmoyano@theke.io --- Comment #36 from Agustín Moyano <agustinmoyano@theke.io> --- (In reply to Tomás Cohen Arazi from comment #35)

This did actually break sql reports with empty parameters.

Yes, we just found out this was the reason why filtered reports didn't work as expected when leaving blank inputs... For example, If you define a report like this: select <<Library|branches:all>> as lib, <<Item type|itemtypes:all>> as itype, <<CC|CC:all>> as cc, <<Date from>> as date_from, <<Date to>> as date_to, <<Invoice>> as invoice and submit the form with one parameter.. for example the one that says 'Invoice' the form posts to the report with the following query string parameters: reports: 41 phase: Run this report param_name: Library|branches:all sql_params: % param_name: Item type|itemtypes:all sql_params: % param_name: CC|CC:all sql_params: % param_name: Date from sql_params: param_name: Date to sql_params: param_name: Invoice sql_params: invoice_1 But after redirection, empty parameters are filtered, leaving things like this reports: 41 phase: Run this report param_name: Library|branches:all sql_params: % param_name: Item type|itemtypes:all sql_params: % param_name: CC|CC:all sql_params: % param_name: Date from param_name: Date to param_name: Invoice sql_params: invoice_1 Notice missing sql_params. This ended up the query to be built like this: select '%' as lib, '%' as itype, '%' as cc, 'invoice_1' as date_from, NULL as date_to, NULL as invoice notice that 'invoice_1' is placed in date_from instead of invoice column. This fix is more awesome than you realized, ;) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25548 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|20.11.00, 20.05.07 |20.11.00, 20.05.07, released in| |19.11.13 --- Comment #38 from Victor Grousset/tuxayo <victor@tuxayo.net> --- Great news then :) Backported to 19.11.x branch for 19.11.13 -- You are receiving this mail because: You are watching all bug changes.