HTTP ਅੱਪਲੋਡ ਰੁਕਾਵਟਾਂ ਅਤੇ Expect: 100-continue

Expect: 100-continue ਦੇ ਅਦਲ-ਬਦਲ ਨੂੰ ਪਛਾਣੋ ਅਤੇ ਇਸ ਦੇ ਛੋਟੇ ਫ਼ੈਸਲਾ-ਬਿੰਦੂ ਨੂੰ ਡੇਟਾ ਭੇਜਦੇ ਸਮੇਂ ਰੁਕੇ ਅੱਪਲੋਡ ਤੋਂ ਵੱਖ ਕਰੋ।

ਕਨੈਕਸ਼ਨ ਖੁੱਲ੍ਹਦਾ ਹੈ। ਬੇਨਤੀ ਹੈਡਰ ਬਾਹਰ ਜਾਂਦੇ ਹਨ। ਫ਼ਾਈਲ ਹਿਲਦੀ ਨਹੀਂ ਦਿਸਦੀ। ਇੱਕ ਵਿਆਖਿਆ ਇਹ ਹੈ ਕਿ ਕਲਾਇੰਟ ਆਪਣਾ ਬਾਡੀ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ Expect: 100-continue ਲਈ ਜਵਾਬ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ।

ਇਹ ਮਕੈਨਿਜ਼ਮ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਸੰਭਾਵੀ ਵੱਡੇ ਅੱਪਲੋਡ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਬੇਨਤੀ ਨੂੰ ਇਸ ਦੇ ਹੈਡਰਾਂ ਤੋਂ ਰੱਦ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਆਮ ਸਫਲ ਕ੍ਰਮ ਇਹ ਹੈ:

request headers → 100 Continue → request body → final response

100 ਜਾਣਕਾਰੀ-ਭਰਪੂਰ ਹੈ: ਇਹ ਕਲਾਇੰਟ ਨੂੰ ਅੱਗੇ ਵਧਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਪਰ ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਫ਼ਾਈਲ ਸੰਭਾਲੀ ਗਈ ਹੈ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਕਾਰਵਾਈ ਸਫਲ ਹੋਈ ਹੈ। HTTP 417 ਵਾਪਸ ਕਰਨ ਵਾਲਾ Git push ਅਜਿਹੀ ਇੱਕ ਠੋਸ ਉਮੀਦ-ਅਸਫਲਤਾ ਦੀ ਮਿਸਾਲ ਹੈ।

ਪਤਾ ਕਰੋ ਕਿ ਕਲਾਇੰਟ ਨੂੰ ਕਿਹੜਾ ਜਵਾਬ ਮਿਲਿਆ

ਨਿਰੀਖਣਕੀ ਜਾਂਚਣਾ ਹੈ
100 Continueਕਲਾਇੰਟ ਬਾਡੀ ਨਾਲ ਅੱਗੇ ਵਧ ਸਕਦਾ ਹੈ
ਬਾਡੀ ਤੋਂ ਪਹਿਲਾਂ ਅੰਤਿਮ ਰੱਦਕਾਰਵਾਈ ਹੈਡਰ ਪੜਾਅ ’ਤੇ ਰੱਦ ਕੀਤੀ ਗਈ
ਕੋਈ ਉਮੀਦ ਕੀਤਾ ਅੰਤਰਿਮ ਜਵਾਬ ਨਹੀਂਕਲਾਇੰਟ ਦੀ ਉਡੀਕ ਨੀਤੀ ਅਤੇ ਉਸ ਰਾਹ ’ਤੇ ਸੰਭਾਲ

curl ਵਿੱਚ expect-continue ਉਡੀਕ ਲਈ ਵੱਖਰੀ ਸੈਟਿੰਗ ਹੈ। ਜੇ ਉਹ libcurl ਉਡੀਕ ਉਮੀਦ ਕੀਤੇ ਜਵਾਬ ਤੋਂ ਬਿਨਾਂ ਖ਼ਤਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਬਾਡੀ ਫਿਰ ਵੀ ਭੇਜਦਾ ਹੈ; ਖ਼ਤਮ ਹੋਣਾ ਆਪਣੇ ਆਪ ਪੂਰੇ ਟ੍ਰਾਂਸਫ਼ਰ ਦੀ ਅਸਫਲਤਾ ਨਹੀਂ। ਇਹ ਸੈਟਿੰਗ ਪੂਰੇ ਟ੍ਰਾਂਸਫ਼ਰ ਲਈ ਦਿੱਤੇ ਸਮੇਂ ਤੋਂ ਵੱਖਰੀ ਹੈ। ਬਾਅਦ ਵਾਲਾ ਵਧਾਉਣ ਨਾਲ ਉਹੀ ਸ਼ੁਰੂਆਤੀ ਰੁਕਾਵਟ ਬਿਨਾਂ ਵਿਆਖਿਆ ਦੇ ਰਹਿ ਸਕਦੀ ਹੈ।

ਇਹ ਵੀ ਪਛਾਣੋ ਕਿ ਕਿਹੜੀ HTTP ਗੱਲਬਾਤ Expect ਲੈ ਕੇ ਜਾਂਦੀ ਹੈ। HTTPS ਮੰਤਵ ਵੱਲ ਆਮ CONNECT ਨਾਲ, ਵੈੱਬਸਾਈਟ ਦਾ ਅੱਪਲੋਡ ਅਦਲ-ਬਦਲ TLS ਦੇ ਅੰਦਰ ਹੁੰਦਾ ਹੈ; ਫ਼ਾਰਵਰਡ ਪ੍ਰੌਕਸੀ ਇਸ ਦੇ ਅੰਦਰਲੇ ਉਮੀਦ ਹੈਡਰ ਨੂੰ ਸਿੱਧਾ ਨਹੀਂ ਵੇਖਦੀ। ਰੋਕਣ ਜਾਂ ਸਾਦਾ-ਪਾਠ ਫ਼ਾਰਵਰਡਿੰਗ ਦਾ ਰਾਹ ਵੱਖਰਾ ਹੈ।

ਉਮੀਦ ਹਟਾਉਣਾ ਜਾਣ-ਬੁੱਝ ਕੇ ਅਨੁਕੂਲਤਾ ਦੀ ਚੋਣ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਲਾਇੰਟ ਜਲਦੀ ਰੱਦ ਬਾਰੇ ਜਾਣਨ ਤੋਂ ਪਹਿਲਾਂ ਵੱਡਾ ਬਾਡੀ ਭੇਜਣਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ। ਉਸ ਵਿਵਹਾਰ ਦੀ ਅਸਲ ਲੋੜ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਪੁਰਾਣੀ ਪ੍ਰੌਕਸੀ ਲਈ ਇਤਿਹਾਸਕ ਹੱਲ ਨੂੰ ਹਰ ਅੱਪਲੋਡ ਤੋਂ ਹੈਡਰ ਹਟਾਉਣ ਦੀ ਸਰਵਵਿਆਪੀ ਹਦਾਇਤ ਵਜੋਂ ਨਾ ਦੱਸੋ।

ਸੰਬੰਧਿਤ ਲੇਖ