requests: stream parameter is noop
MicroPython v1.21.0; Raspberry Pi Pico W with RP2040.
requests.request exposes a stream=None parameter:
https://github.com/micropython/micropython-lib/blob/d8e163bb5f3ef45e71e145c27bc4f207beaad70f/python-ecosys/requests/requests/init.py#L36-L46
but it is never functionally used, nor is some iter_content API exposed; the parameter is only forwarded to recursive request calls.
Workaround:
r = requests.get(...)
# sidestep @property content, which just reads socket data into memory until EOF
s = r.raw
r.raw = None
buf = bytearray(1024)
while s.readinto(buf) > 0:
# handle data in buf (e.g. write to file)
if the above is implemented into some iter_content, is the stream parameter even needed? Am I missing something?
TCP socket RESET's the connection when not reading the entire read buffer
Port, board and/or hardware
W5500-EVB-Pico, Raspberry Pi Pico W
MicroPython version
MicroPython v1.24.1 on 2024-11-29; W5500-EVB-Pico with RP2040
Reproduction
When not reading the entire TCP message, micropython will RESET the connection, instead of doing a proper TCP connection teardown.
Example:
import network
from machine import SPI, Pin
import time
import asyncio
def w5x00_init():
# https://github.com/Wiznet/RP2040-HAT-MicroPython/blob/main/Ethernet%20Example%20Getting%20Started%20%5BMicropython%5D.md
spi=SPI(0,2_000_000, mosi=Pin(19),miso=Pin(16),sck=Pin(18))
nic = network.WIZNET5K(spi,Pin(17),Pin(20))
nic.active(True)
nic.ifconfig('dhcp')
while not nic.isconnected():
time.sleep(1)
print(nic.regs())
print(nic.ifconfig())
async def handle_client_read_1000(r, w):
await r.read(1000)
w.write(b'HTTP/1.0 200 OK\r\nContent-Length: 2\r\nContent-Type: text/plain\r\n\r\nhi')
w.close()
await w.wait_closed()
async def server_async(handle_client):
await asyncio.start_server(handle_client, '0.0.0.0', 80)
while True:
await asyncio.sleep(1)
w5x00_init()
asyncio.run(server_async(handle_client_read_1000))
Expected behaviour
Reading parts of the TCP stream/reading the entire stream/not reading the stream should not change the behavior of writing into the stream.
When running the same code (except the network setup) in CPython it does a proper TCP connection teardown and does not send RESET.
Observed behaviour
When doing
curl 192.168.2.127
we get a TCP connection teardown after the payload has been send (FIN-ACK):
But when sending a message longer then the buffer (here 1000B) via
curl 192.168.2.127/hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
we get
I.e. it sends RESET instead of doing a proper connection teardown.
This causes various strange behaviors as seen in the original discussion.
Additional Information
See the original discussion
Code of Conduct
Yes, I agree