@@ -6,22 +6,22 @@ Session management
6
6
7
7
Zyte API provides powerful session APIs:
8
8
9
- - :ref: `Client-managed sessions <zyte-api -session-id >` give you full control
9
+ - :ref: `Client-managed sessions <zapi -session-id >` give you full control
10
10
over session management.
11
11
12
- - :ref: `Server-managed sessions <zyte-api -session-contexts >` let Zyte API
12
+ - :ref: `Server-managed sessions <zapi -session-contexts >` let Zyte API
13
13
handle session management for you.
14
14
15
15
When using scrapy-zyte-api, you can use these session APIs through the
16
16
corresponding Zyte API fields (:http: `request:session `,
17
17
:http: `request:sessionContext `).
18
18
19
19
However, scrapy-zyte-api also provides its own session management API, similar
20
- to that of :ref: `server-managed sessions <zyte-api -session-contexts >`, but
21
- built on top of :ref: `client-managed sessions <zyte-api -session-id >`.
20
+ to that of :ref: `server-managed sessions <zapi -session-contexts >`, but
21
+ built on top of :ref: `client-managed sessions <zapi -session-id >`.
22
22
23
23
scrapy-zyte-api session management offers some advantages over
24
- :ref: `server-managed sessions <zyte-api -session-contexts >`:
24
+ :ref: `server-managed sessions <zapi -session-contexts >`:
25
25
26
26
- You can perform :ref: `session validity checks <session-check >`, so that the
27
27
sessions of responses that do not pass those checks are refreshed, and the
@@ -35,11 +35,11 @@ scrapy-zyte-api session management offers some advantages over
35
35
:ref: `optimize-sessions ` and :ref: `session-configs `.
36
36
37
37
However, scrapy-zyte-api session management is not a replacement for
38
- :ref: `server-managed sessions <zyte-api -session-contexts >` or
39
- :ref: `client-managed sessions <zyte-api -session-id >`:
38
+ :ref: `server-managed sessions <zapi -session-contexts >` or
39
+ :ref: `client-managed sessions <zapi -session-id >`:
40
40
41
- - :ref: `Server-managed sessions <zyte-api -session-contexts >` offer a longer
42
- life time than the :ref: `client-managed sessions <zyte-api -session-id >`
41
+ - :ref: `Server-managed sessions <zapi -session-contexts >` offer a longer
42
+ life time than the :ref: `client-managed sessions <zapi -session-id >`
43
43
that scrapy-zyte-api session management uses, so as long as you do not need
44
44
one of the scrapy-zyte-api session management features, server-managed
45
45
sessions can be significantly more efficient (fewer total sessions needed
@@ -49,7 +49,7 @@ However, scrapy-zyte-api session management is not a replacement for
49
49
website. With scrapy-zyte-api session management, you need to :ref: `handle
50
50
optimization yourself <optimize-sessions>`.
51
51
52
- - :ref: `Client-managed sessions <zyte-api -session-id >` offer full control
52
+ - :ref: `Client-managed sessions <zapi -session-id >` offer full control
53
53
over session management, while scrapy-zyte-api session management removes
54
54
some of that control to provide an easier API for supported use cases.
55
55
@@ -68,7 +68,7 @@ override <session-configs>`.
68
68
.. _session-init-default :
69
69
70
70
By default, scrapy-zyte-api will maintain up to 8 sessions per domain, each
71
- initialized with a :ref: `browser request <zyte-api -browser >` targeting the URL
71
+ initialized with a :ref: `browser request <zapi -browser >` targeting the URL
72
72
of the first request that will use the session. Sessions are automatically
73
73
rotated among requests, and refreshed as they expire or get banned. You can
74
74
customize most of this logic though request metadata, settings and
@@ -134,7 +134,7 @@ To change the :ref:`default session initialization parameters
134
134
:reqmeta: `zyte_api_session_params ` request metadata key.
135
135
136
136
It works similarly to :http: `request:sessionContextParams ` from
137
- :ref: `server-managed sessions <zyte-api -session-contexts >`, but it supports
137
+ :ref: `server-managed sessions <zapi -session-contexts >`, but it supports
138
138
arbitrary Zyte API parameters instead of a specific subset.
139
139
140
140
If it does not define a ``"url" ``, the URL of the request :ref: `triggering
@@ -210,7 +210,7 @@ initialization request.
210
210
If your session checking implementation relies on the response body (e.g. it
211
211
uses CSS or XPath expressions), you should make sure that you are getting one,
212
212
which might not be the case if you are mostly using :ref: `Zyte API automatic
213
- extraction <zyte-api -extract>`, e.g. when using :doc: `Zyte spider templates
213
+ extraction <zapi -extract>`, e.g. when using :doc: `Zyte spider templates
214
214
<zyte-spider-templates:index>`. For example, you can use
215
215
:setting: `ZYTE_API_AUTOMAP_PARAMS ` and :setting: `ZYTE_API_PROVIDER_PARAMS ` to
216
216
force :http: `request:browserHtml ` or :http: `request:httpResponseBody ` to be set
@@ -288,7 +288,7 @@ Here are some things you can try:
288
288
(:setting: `ZYTE_API_SESSION_POOL_SIZE `). The more different sessions you
289
289
use, the more slowly you send requests through each session.
290
290
291
- Mind, however, that :ref: `client-managed sessions <zyte-api -session-id >`
291
+ Mind, however, that :ref: `client-managed sessions <zapi -session-id >`
292
292
expire after `15 minutes since creation or 2 minutes since the last request
293
293
<https://docs.zyte.com/zyte-api/usage/reference.html#operation/extract/request/session> `_.
294
294
At a certain point, increasing :setting: `ZYTE_API_SESSION_POOL_SIZE `
@@ -298,7 +298,7 @@ Here are some things you can try:
298
298
counterproductive.
299
299
300
300
- By default, sessions are discarded as soon as an :ref: `unsuccessful
301
- response <zyte-api -unsuccessful-responses>` is received.
301
+ response <zapi -unsuccessful-responses>` is received.
302
302
303
303
However, on some websites sessions may remain valid even after a few
304
304
unsuccessful responses. If that is the case, you might want to increase
@@ -308,9 +308,9 @@ Here are some things you can try:
308
308
If you do not need :ref: `session checking <session-check >` and your
309
309
:ref: `initialization parameters <session-init >` are only
310
310
:http: `request:browserHtml ` and :http: `request:actions `, :ref: `server-managed
311
- sessions <zyte-api -session-contexts>` might be a more cost-effective choice, as
311
+ sessions <zapi -session-contexts>` might be a more cost-effective choice, as
312
312
they live much longer than :ref: `client-managed sessions
313
- <zyte-api -session-id>`.
313
+ <zapi -session-id>`.
314
314
315
315
316
316
.. _session-configs :
@@ -371,7 +371,7 @@ To include cookies in session initialization requests, use
371
371
:http: `request:requestCookies ` in :ref: `session initialization parameters
372
372
<session-init>`. But mind that those cookies are only set during that request,
373
373
:ref: `they are not added to the session cookie jar
374
- <zyte-api -session-cookie-jar>`.
374
+ <zapi -session-cookie-jar>`.
375
375
376
376
377
377
Session retry policies
@@ -441,7 +441,7 @@ The following stats exist for scrapy-zyte-api session management:
441
441
442
442
``scrapy-zyte-api/sessions/pools/{pool}/init/failed ``
443
443
Number of times that initializing a session for pool ``{pool} `` resulted in
444
- an :ref: `unsuccessful response <zyte-api -unsuccessful-responses >`.
444
+ an :ref: `unsuccessful response <zapi -unsuccessful-responses >`.
445
445
446
446
``scrapy-zyte-api/sessions/pools/{pool}/init/param-error ``
447
447
Number of times that initializing a session for pool ``{pool} `` triggered
@@ -473,7 +473,7 @@ The following stats exist for scrapy-zyte-api session management:
473
473
474
474
``scrapy-zyte-api/sessions/pools/{pool}/use/failed ``
475
475
Number of times that a request that used a session from pool ``{pool} ``
476
- got an :ref: `unsuccessful response <zyte-api -unsuccessful-responses >`.
476
+ got an :ref: `unsuccessful response <zapi -unsuccessful-responses >`.
477
477
478
478
``scrapy-zyte-api/sessions/use/disabled ``
479
479
Number of processed requests for which session management was disabled.
0 commit comments