(0x600001094100),
Codes = [...].
```
In particular, note that `P0 = P1`, even though I’ve read several hundred bytes.
Is this expected behaviour, that after reading from the (child) stream we get the same value for the position on the (parent) stream before and after the read?
---
### Author:  [@jan](https://swi-prolog.discourse.group/u/jan)
#### Post date: [April 28, 2025, 5:58pm UTC](https://swi-prolog.discourse.group/t/multipart-open-does-not-advance-the-streams-pointer/8965/2 "2025-04-28T17:58:17Z")
Hi Matt, long time no see 🙂 multipart\_read() calls S\_\_fillbuf() and updated bufp at line 192. Nothing however updates the parent stream’s position data. I guess that is wrong. Not sure how much value there is in this. Note that it is a binary stream, so basically only the byte position is relevant. I think we could update that with the update of bufp?
Are you dealing with multipart documents that are embedded into other streams?
---
### Author:  [@matt.lilley](https://swi-prolog.discourse.group/u/matt.lilley)
#### Post date: [April 29, 2025, 7:19am UTC](https://swi-prolog.discourse.group/t/multipart-open-does-not-advance-the-streams-pointer/8965/3 "2025-04-29T07:19:21Z")
It calls `S__fillbuf()` but only if there’s not enough data in the stream buffer, which in my case, there is ☹
My use case is possibly a bit weird - and the underlying issue may have actually been fixed in a later version of Prolog. The gist is (according to my notes from 2 years ago on the ticket) that I’m dealing with HTTP post requests in keep-alive connections. In the case where the handler reads only one part of the multipart document (for example, if the same content is represented in both text and HTML), processes it, and succeeds, the socket is left with the rest of the multipart document pending on it, meaning the thread reading the next request receives a lot of unexpected stuff (the remainder of the previous request). To fix this, I wrapped the multipart handler in a predicate which gets the current stream position at the start of the handler, gets the stream position at the end, looks at the content-length (it’s more complex with chunked, but you get the idea) and then discards the unread part of the body. Obviously this doesn’t work if the stream pointer hasn’t been updated as the stream has been processed.
It might be as simple as moving stream-\>bufp after successfully consuming the data in the stream…
---
### Author:  [@jan](https://swi-prolog.discourse.group/u/jan)
#### Post date: [April 29, 2025, 8:04am UTC](https://swi-prolog.discourse.group/t/multipart-open-does-not-advance-the-streams-pointer/8965/4 "2025-04-29T08:04:32Z")
Sounds like a valid use case. I pushed [FIXED: Multipart reader to update stream position data of parent stream. · SWI-Prolog/packages-http@c87298b · GitHub](https://github.com/SWI-Prolog/packages-http/commit/c87298b7045909753f06326c04bf6f2cdf1ca60d). This may address the issue. I don’t think it is it `bufp` that is the problem as that is not used by getting the position data. Surely the commit should improve on the current state 🙂
If this fails, can you share the data file such that I can reproduce the behaviour?
---
### Author:  [@matt.lilley](https://swi-prolog.discourse.group/u/matt.lilley)
#### Post date: [April 29, 2025, 9:08am UTC](https://swi-prolog.discourse.group/t/multipart-open-does-not-advance-the-streams-pointer/8965/5 "2025-04-29T09:08:24Z")
That was quick!
I _think_ this is right - the only caveat is that when I read from the parent stream, I still see the `0x10` at the end of the boundary (the 0x13 is consumed though).
This still works OK for my test case (I think; I’m doing testing now), but I thought I should mention it anyway.
As for the test case, the base64 encoding of the file I’m loading in my test case (winraw.txt) is
```prolog
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0yY2IxMGVjOTAyODE3MDU0DQpDb250ZW50LURpc3Bvc2l0aW9uOiBmb3JtLWRhdGE7IG5hbWU9ImZpbGUiOyBmaWxlbmFtZT0idGVzdF9hdHRhY2hlbWVudC50eHQiDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW4NCg0KMTIzNDUKYXNkZmcNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tMmNiMTBlYzkwMjgxNzA1NA0KQ29udGVudC1EaXNwb3NpdGlvbjogZm9ybS1kYXRhOyBuYW1lPSJmaWxlIjsgZmlsZW5hbWU9InJlYWRtZS50eHQiDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW4NCg0KMTIzNDUKNjc4OTANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tMmNiMTBlYzkwMjgxNzA1NC0tDQo=
```
(This is probably easier than trying to work out how to upload a text file with the correct line endings in it)
Then I run
```prolog
open('/tmp/winraw.txt', read, S), stream_property(S, position(P0)), multipart_open(S, M, [boundary('------------------------2cb10ec902817054')]), read_line_to_codes(M, Codes), stream_property(S, position(P1))
```
---
### Author:  [@matt.lilley](https://swi-prolog.discourse.group/u/matt.lilley)
#### Post date: [April 29, 2025, 9:13am UTC](https://swi-prolog.discourse.group/t/multipart-open-does-not-advance-the-streams-pointer/8965/6 "2025-04-29T09:13:07Z")
Also, I’ve found the very original ticket that lead me down this rabbit hole 🙂 (some text removed)
> A pentest vulnerability report provisioned by … highlighted an issue with HTTP request smuggling …:
>
> In the SWI-Prolog webserver it is the responsibility of the HTTP handler to consume bytes from the HTTP request’s body. This leaves the possibility that the request body is not fully consumed. For example:
```prolog
printf "%s\r\n"
"GET /path1 HTTP/1.1"
"Host: localhost"
"Content-Length: 26"
""
"GET /path2"
"Host:localhost"
""
| nc localhost 8080
```
> Here a single HTTP request is sent to … with the request’s body containing a (smuggled) request. This results in … returning _two_ HTTP responses:
```prolog
HTTP/1.1 200 OK
Date: Tue, 01 Nov 2022 12:47:59 GMT
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
Content-Length: 2289
...