search

buildstream-migration / bst-staging

GNU Lesser General Public License v2.1
0 stars 0 forks source link

Buildstream tar source fails when receiving HTTP code 103 #1124

Open Cynical-Optimist opened 4 years ago

Cynical-Optimist commented 4 years ago

See original issue on GitLab In GitLab by [Gitlab user @abderrahimk] on Sep 7, 2019, 07:14

Summary

One server we're dealing with returns HTTP code 103 "Early Hints", and bst is treating that as an error.

Steps to reproduce

try tracking core-deps/ppp.bst or core-deps/samba.bst on gnome-build-meta commit 3e945aab3d01fe07dbe7da8093cab82de71deb63

What is the current bug behavior?

I get an error https://gitlab.gnome.org/GNOME/gnome-build-meta/-/jobs/421663

What is the expected correct behavior?

It should continue normally, HTTP codes in the 100 range are informational

Possible fixes

https://gitlab.com/BuildStream/buildstream/blob/master/src/buildstream/plugins/sources/_downloadablefilesource.py#

It seems urllib is treating HTTP code 103 as an error.

Other relevant information

Cynical-Optimist commented 4 years ago

In GitLab by [Gitlab user @tpollard] on Sep 9, 2019, 14:55

I would have thought urllib let all exceptions in the 100 range continue if not intercepted

except urllib.error.HTTPError as e:

I expect because we're explicitly entering the exception block for any HTTPError and then raising the sourceerror blindly, we are overriding urllib letting it through by default. We should probably rework that block. On checking the source it seems only the 200 success range is handled internally by default. If we want to support the 100 range as being OK to continue then it would be trivial

Cynical-Optimist commented 4 years ago

In GitLab by [Gitlab user @nanonyme] on Oct 7, 2020, 19:11

This sounds to me like a missing feature in urllib based on the RFC (and possibly discarding its body it while merging headers? RFC says there's a second complete response block after 103 which includes headers which may or may not contain same ones as in 103). At any rate, this doesn't seem like a sane thing for server to respond unless the consumer is a browser.