The timeouts in settings.yml is about the total time (not only the HTTP request but also the prepare the request and parsing the response)
It was more or less the case before since the threaded_requests function ignores the thread after the timeout even the HTTP request is ended.
New / changed stats :
* page_load_time : record the HTTP request time
* page_load_count: the number of HTTP request
* engine_time : the execution total time of an engine
* engine_time_count : the number of "engine_time" measure
The avg response times in the preferences are the engine response time (engine_load_time / engine_load_count)
To sum up :
* Search.search() filters the engines that can't process the request
* Search.search() call search_multiple_requests function
* search_multiple_requests creates one thread per engine, each thread runs the search_one_request function
* search_one_request calls the request function, make the HTTP request, calls the response function, extends the result_container
* search_multiple_requests waits for the the thread to finish (or timeout)
- pre_search(request, search)
- post_search(request, search)
- on_result(request, search, result)
with
- request is the Flask request
- search a searx.Search instance
- result a searx result as usual
Purposes :
- isolate the plugins calls
- distinction between parsing the web request and running the search (Search class). To be able to test code easily, to run searx code outside a web server, to filter the search query parameters with plugins more easily, etc...
Details :
- request.request_data contains request.form or request.args (initialize inside pre_request() function)
- Query class is renamed RawTextQuery
- SearchQuery class defines all search parameters
- get_search_query_from_webapp create a SearchQuery instance (basically the previous Search.__init__ code)
- Search class and SearchWithPlugins class takes a SearchQuery instance as class constructor parameter
- SearchWithPlugins class inherites from Search class, and run plugins
- A dedicated function search_with_plugins executes plugins to have a well define locals() (which is used by the plugins code).
- All plugins code is executed inside the try...except block (webapp.py, index function)
- advanced_search HTTP parameter value stays in webapp.py (it is only part of UI)
- multiple calls to result_container.get_ordered_results() doesn't compute the order multiple time (note : this method was call only once before)
- paging value is stored in the result_container class (compute in the extend method)
- test about engine.suspend_end_time is done during search method call (instead of __init__)
- check that the format parameter value is one of these : html, rss, json, rss (before the html value was assumed but some text formatting wasn't not done)
This allow to send request to google.* (according to the search language).
Before this commit, request in other languages than english was sent to www.google.com which was redirected to www.google.*
The PREF is still use on the www.google.com domain.
The currency names are fetched wikidata and store into a static file : searx/data/currencies.json
This file is loaded when the currency_converter is loaded.
A database is perhaps more appropiated.
Sometimes there is two requests to google (depending of the source IP) : one to google.com, the second to google.fr (for instance).
Going to https://www.google.com/ncr and saving the PREF cookie for future use prevent this (there is no redirection).
But, recently (or not ?), by doing this the search returns English results even if the Accept-Language is specified.
There is still a way to prevent this : going to preference, set the search language. I don't know if this can be done by searx.
For now, a quick fix is to disable the use of the PREF cookie when the search language is not English (google engine will slower but returns excepted results).
locale was declared for bing* engines and vimeo.
* bing* engines use the language settings.
* vimeo uses neither locale nor language settings.
This avoid confusion
Close#197 perhaps not in clean way. Explanation :
In fact 301 responses are followed, except the hook is called for each HTTP response,
the first time for the HTTP 301 response then for HTTP 200 response.
Since the kickass engine excepts a real result, the engine crashes, AND the requests lib stops here.
Add a simple test at the beginning of the result function allows pass the first response and handle correctly the second response (the real one)
May be a proper way is to add this test in search.py ?
Code inside requests :
https://github.com/kennethreitz/requests/blob/53d02381e22436b6d0757eb305eb1a960f82d361/requests/sessions.py#L579
and line 591
Close#197 perhaps not in clean way. Explaination :
In fact 301 responses are followed, except the hook is called for each HTTP response,
the first time for the HTTP 301 response then for HTTP 200 response.
Since the kickass engine excepts a real result, the engine crashes, AND the requests lib stops here.
Add a simple test at the begining of the result function allows pass the first response and handle correctly the second response (the real one)
May be a proper way is to add this test in search.py ?
Code inside requests :
https://github.com/kennethreitz/requests/blob/53d02381e22436b6d0757eb305eb1a960f82d361/requests/sessions.py#L579
and line 591
- more smartphone friendly
- more text browser friendly
- next button always on the right
- in case of small screen supporting touch event, categories are displayed on one line with a scroll
Alexandre Flament