લાંબી HTTP કામગીરી દરમિયાન પ્રોક્સીના નિષ્ક્રિય સમયમર્યાદા
જ્યારે લાંબુ સર્વર કામ પ્રોક્સીની નિષ્ક્રિય મર્યાદાને ભેટે ત્યારે અંતિમ પ્રતિસાદમાં મનસ્વી બાઇટ્સ દાખલ કરવાને બદલે પોલિંગ અથવા નિર્ધારિત સ્ટ્રીમિંગ ફોર્મેટ પસંદ કરો.
જો કોઈ સેવા મિનિટો સુધી શાંત રહે અને પ્રોક્સીનો સમય પૂરો થાય, તો હાર્ટબીટ બાઇટ્સ ઉમેરતા પહેલાં ક્લાયન્ટને શું મળવું જોઈએ તે પસંદ કરો. ટાઈમર લંબાવવાથી એક પ્રતીક્ષામાં મદદ મળી શકે; પ્રતિસાદ કરાર નક્કી કરે છે કે કઈ પ્રગતિ માન્ય છે.
| એપ્લિકેશન ડિઝાઇન | પ્રગતિ કરાર |
|---|---|
| એસિન્ક્રોનસ કામ | મોનિટરિંગનું વર્ણન કરતી રજૂઆત સાથે 202 Accepted, ત્યારપછી મર્યાદિત સ્થિતિ વિનંતીઓ અને સ્પષ્ટ પૂર્ણતા/નિષ્ફળતા સ્થિતિઓ |
| Server-Sent Events સ્ટ્રીમ | Content-Type: text/event-stream અને રેકોર્ડ કે જે SSE ક્લાયન્ટ સમજે છે |
202 વચન આપતું નથી કે કામ સફળ થશે. SSE માટે, ટિપ્પણી રેકોર્ડ આવો દેખાઈ શકે:
: heartbeat
કોલન તેને એપ્લિકેશન ઘટનાને બદલે ટિપ્પણી બનાવે છે. HTMLની લેખન નોંધો કેટલાક જૂના પ્રોક્સી નિષ્ક્રિય વર્તન સામે લગભગ દર 15 સેકન્ડે સામયિક ટિપ્પણીઓ સૂચવે છે; તે માર્ગદર્શન છે, સાર્વત્રિક સમયમર્યાદા બાંયધરી નથી.
હેડર્સ પૂર્ણ કરો અને ખાતરી કરો કે એપ્લિકેશન/સેવા સ્ટેક રેકોર્ડ્સને સ્થાનિક રીતે બફર કરવાને બદલે મુક્ત કરે છે. હજુ સુધી ન મોકલેલા બાઇટ્સ ડાઉનસ્ટ્રીમ મધ્યસ્થને સક્રિય રાખી શકતા નથી.
સામાન્ય JSON અથવા બાઈનરી સામગ્રીમાં SSE ટિપ્પણીઓ દાખલ કરશો નહીં. HTTP/1.1 નો શૂન્ય-લંબાઈનો chunk chunked બોડી સમાપ્ત કરે છે, તેથી તે પુનરાવર્તનયોગ્ય ખાલી હાર્ટબીટ નથી.
ઓપરેશન સમયમર્યાદા અને રદ કરવાની નીતિ રાખો. ફક્ત ટ્રાફિક પ્રવૃત્તિ ઉપયોગી કામ પ્રગતિ કે માન્ય અંતિમ પરિણામ દર્શાવતી નથી.