ਲੰਬੇ HTTP ਕੰਮਾਂ ਦੌਰਾਨ ਪ੍ਰੌਕਸੀ ਦੇ ਨਿਸ਼ਕਿਰਿਆ ਟਾਈਮਆਊਟ
ਜਦੋਂ ਲੰਬਾ ਸਰਵਰ ਕੰਮ ਪ੍ਰੌਕਸੀ ਦੀ ਨਿਸ਼ਕਿਰਿਆ ਸੀਮਾ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਤਾਂ ਅੰਤਿਮ ਜਵਾਬ ਵਿੱਚ ਮਨਮਾਨੇ ਬਾਈਟ ਪਾਉਣ ਦੀ ਬਜਾਏ ਪੋਲਿੰਗ ਜਾਂ ਨਿਰਧਾਰਤ ਸਟ੍ਰੀਮਿੰਗ ਫਾਰਮੈਟ ਚੁਣੋ।
ਜੇ ਸੇਵਾ ਕਈ ਮਿੰਟ ਚੁੱਪ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਪ੍ਰੌਕਸੀ ਦਾ ਸਮਾਂ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਹਾਰਟਬੀਟ ਬਾਈਟ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਚੁਣੋ ਕਿ ਕਲਾਇੰਟ ਨੂੰ ਕੀ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਟਾਈਮਰ ਵਧਾਉਣਾ ਇੱਕ ਉਡੀਕ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ; ਜਵਾਬ ਸਮਝੌਤਾ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਪ੍ਰਗਤੀ ਵੈਧ ਹੈ।
| ਐਪਲੀਕੇਸ਼ਨ ਡਿਜ਼ਾਈਨ | ਪ੍ਰਗਤੀ ਸਮਝੌਤਾ |
|---|---|
| ਅਸਿੰਕ੍ਰੋਨਸ ਕੰਮ | ਨਿਗਰਾਨੀ ਦਾ ਵਰਣਨ ਕਰਨ ਵਾਲੀ ਪੇਸ਼ਕਾਰੀ ਨਾਲ 202 Accepted, ਫਿਰ ਸੀਮਿਤ ਸਥਿਤੀ ਬੇਨਤੀਆਂ ਅਤੇ ਸਪੱਸ਼ਟ ਪੂਰਨਤਾ/ਅਸਫਲਤਾ ਸਥਿਤੀਆਂ |
| Server-Sent Events ਸਟ੍ਰੀਮ | Content-Type: text/event-stream ਅਤੇ ਰਿਕਾਰਡ ਜੋ SSE ਕਲਾਇੰਟ ਸਮਝਦਾ ਹੈ |
202 ਵਾਅਦਾ ਨਹੀਂ ਕਰਦਾ ਕਿ ਕੰਮ ਸਫਲ ਹੋਵੇਗਾ। SSE ਲਈ, ਟਿੱਪਣੀ ਰਿਕਾਰਡ ਇੰਝ ਦਿਖ ਸਕਦਾ ਹੈ:
: heartbeat
ਕੋਲਨ ਇਸਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਇਵੈਂਟ ਦੀ ਬਜਾਏ ਟਿੱਪਣੀ ਬਣਾਉਂਦਾ ਹੈ। HTML ਦੇ ਲੇਖਣ ਨੋਟ ਕੁਝ ਪੁਰਾਣੇ ਪ੍ਰੌਕਸੀ ਨਿਸ਼ਕਿਰਿਆ ਵਿਵਹਾਰ ਦੇ ਖਿਲਾਫ ਲਗਭਗ ਹਰ 15 ਸਕਿੰਟ ਵਿੱਚ ਆਵਰਤੀ ਟਿੱਪਣੀਆਂ ਦਾ ਸੁਝਾਅ ਦਿੰਦੇ ਹਨ; ਇਹ ਮਾਰਗਦਰਸ਼ਨ ਹੈ, ਸਰਵਵਿਆਪੀ ਟਾਈਮਆਊਟ ਗਾਰੰਟੀ ਨਹੀਂ।
ਹੈਡਰ ਪੂਰੇ ਕਰੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਐਪਲੀਕੇਸ਼ਨ/ਸੇਵਾ ਸਟੈਕ ਰਿਕਾਰਡਾਂ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਬਫਰ ਕਰਨ ਦੀ ਬਜਾਏ ਛੱਡਦਾ ਹੈ। ਅਜੇ ਨਾ ਭੇਜੇ ਗਏ ਬਾਈਟ ਡਾਊਨਸਟ੍ਰੀਮ ਵਿਚੋਲੇ ਨੂੰ ਸਰਗਰਮ ਨਹੀਂ ਰੱਖ ਸਕਦੇ।
ਆਮ JSON ਜਾਂ ਬਾਈਨਰੀ ਸਮੱਗਰੀ ਵਿੱਚ SSE ਟਿੱਪਣੀਆਂ ਨਾ ਪਾਓ। HTTP/1.1 ਦਾ ਜ਼ੀਰੋ-ਲੰਬਾਈ chunk chunked ਬਾਡੀ ਖਤਮ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਦੁਹਰਾਉਣ ਯੋਗ ਖਾਲੀ ਹਾਰਟਬੀਟ ਨਹੀਂ ਹੈ।
ਕਾਰਵਾਈ ਦੀ ਸਮਾਂ-ਸੀਮਾ ਅਤੇ ਰੱਦ ਕਰਨ ਦੀ ਨੀਤੀ ਰੱਖੋ। ਸਿਰਫ ਟ੍ਰੈਫਿਕ ਗਤੀਵਿਧੀ ਲਾਭਦਾਇਕ ਕੰਮ ਪ੍ਰਗਤੀ ਜਾਂ ਵੈਧ ਅੰਤਿਮ ਨਤੀਜਾ ਨਹੀਂ ਦਿਖਾਉਂਦੀ।