jiebi/CodeConvo huggingface dataset:
Mostly editorial, but touches normative text.
I'm looking for an additional qualification on the statement, something like: Originally posted by NAME in URL
NAME also suggested a reframing to "SHOULD": Originally posted by NAME in URL (Also, should we rename the "safe-method-w-body" label to "query-method", now that that naming thing is settled. It took me a while to remember the right label.)
I'm not confident that implementers will always know what might be sensitive and probably should not expose any of the payload in the URL. I think the qualifier doesn't reduce the suggestion's practical scope at all, so if it gets us to consensus, let's add it.
I'm less concerned about this ending up in logs than you are, it seems :) For me, the risk that a server log might have sensitive information is already at 100%, which means that log processing needs to include considerable care as far as privacy and security risks go.
Both variants work for me, and IMHO are better than what we have now. Mike, pick one :-)
Query media types could evolve whose syntax allows for specification of elements that the user/user-agent considers "sensitive", and also the server could know from the schema of the underlying data. But really I think a big hammer is needed here: the default should be that servers encode none of the query contents into the resulting user-agents should be able to request that behavior with a request header (e.g., ) But user-agents should also be able to request that the resulting encode as much as possible of the request body so that the user can end up having a URI that can form part of the UI. This should be completely as far as the server is concerned, and will not always be possible due to URI length constraints and/or the difficulty of encoding complex queries in URI local-parts and q-params.
I believe that should be completely up to the server.
I'm inclined to agree with Julian here. From the client's perspective, the server is a monolith -- in the course of handling the request, the server necessarily sees the contents and the data (multi-party compute schemes notwithstanding) and the client trusts it to do so according to whatever privacy policy exists. It's the server operator's issue whether they wish to keep certain information out of their logs in order to reduce how tightly access to their logs must be managed.
Plus, it's implementation guidance at this point, not protocol conformance. We point out the concern and let people in the real world figure out how they navigate it.
An optional header by which the client can request a URI that encodes the query (which may not be feasible, but often will be) vs. not, seems like a good idea to me -- the server doesn't have to grant the client's wish, but having this request header specified will result in better usability. (To go with this an optional response header by which to indicate which option the server went with would be nice.)
This is all so conditional that I wonder whether it even needs a SHOULD (NOT). Would it be enough to say instead. The other options are fine.
Also, can someone explain what the following paragraph is saying, because I'm having a difficult time parsing it.
The next paragraph is trying to say that if you receive HoL blocked stream data at a relay you should try to forward what you have. The goal is to mitigate accumulating latency at every relay hop. I think this makes sense in two cases: You receive data that you know to be within an object you have already seen the header for. Eg: the object length is 100 and you miss bytes 0-49 but get 50-99, you can forward 50-99, as long as your QUIC library supports out of order reads and writes to a stream (not many presently do). This also applies when the object has no length and occupies the entire stream. You are missing some object data for object N on a stream, but you receive the header for object N + 1. This is (potentially) less problematic since the relay might be able to open a new stream to forward it, so out-of-order stream write APIs are not required. In any case, the text probably needs clarification, and perhaps moving from SHOULD (but we know you won't) to MAY is warranted?
Should we mention that a relay should start sending object as soon as the object can be identified (after the header)? Since the draft points out latency as a big deal, it seems this is a must have if we want to cover ULL cases
+1.
It used to be in but was removed. The text was pretty simple: I think and the agreement was to put it into some non-existent latency section.
+1 We should add a recommendation text for Relays to address the request from NAME
sooner is better I do think this might be interpreted by some people in an over zealous sort of way ( like turning off nagle type things ). I do wonder about just using MAY. But happy either way. SHOULD and MAY mean the same thing.
Fixes URL
NAME could you take a look?
Comment by NAME This is rather unimportant, but I just wanted to mention it in case the authors find it useful. Feel free to ignore. The document states that there are no new security considerations, but that's perhaps not quite true. I think it might be useful to call out that an implementation cannot rely on its peer behaving correctly, so implementers will have to take into account they may still receive oversized frames from misbehaving clients. This is arguably no different from the situation today, so it can be argued that the current considerations are accurate. I just thought it might be useful to call it out so some engineer doesn't remove validation checks since the other side is supposed to behave now. Just because we have standards, doesn't mean that everyone complies.
RFC8878 says in its security considerations: Perhaps we could add something like: "Decoders still need to take into account that they can receive oversized frames that do not follow the window size limit specified in this document and fail decoding when such invalid frames are received." NAME Thoughts?
We could do something explicit like that, yeah. But I'm partial to just broadening the existing statement a little: This seems sufficient to me because this issue is called out explicitly in para 4 there (URL). What do you think, NAME NAME
Don't have strong opinions, but I think maybe adding a sentence explicitly about the window size limit is good, given the document is specifically about enforcing the window size limit. This will ensure nobody misses it even if they don't click through the reference to RFC8878.
For
[x] (7.6.3) Via "If a port is not provided, a recipient MAY interpret that as meaning it was received on the default TCP port, if any, for the received-protocol." So if received-protocol is "3", it's a UDP port. If received-protocol is "1" or "1.1", is the default port 80 or 443? IIUC the scheme isn't included to determine this. Editors: URL [x] (7.7) Message Transformations "A proxy that transforms the content of a 200 (OK) response can inform downstream recipients that a transformation has been applied by changing the response status code to 203 (Non-Authoritative Information)" Why not an normative word, instead of "can"? Editors: URL [x] (12.5.3) Is it correct that "identity" and having no field value for Accept-Encoding are synonymous? Editors: URL [x] "Servers that fail a request due to an unsupported content coding ought to respond with a 415 (Unsupported Media Type) status" Why not s/ought to/SHOULD ? Editors: URL [x] (14.3) Why can only origin servers send "Accept-Ranges: bytes"? Why not intermediaries? Editors: URL [x] (15.3.7) "A sender that generates a 206 response with an If-Range header field"... (13.1.5) leads me to believe that only clients can send If-Range. So how can there be a response with If-Range? Editors: URL [x] (15.3.7.2) The last instance of THISSTRINGSEPARATES has a trailing '--'. If this is intentional, it ought to be explained. Editors: URL [x] (16.3.1) says field names SHOULD begin with a letter, but (16.3.2.1) says they SHOULD begin with "an alphanumeric character". More broadly, the "Field name:" description in (16.3.1) should probably refer to (16.3.2.1) unless I'm misunderstanding the scope of these sections.
Editors: URL [x] (17.13) s/TCP behavior/TCP or QUIC behavior Editors: URL [x] (B) It would be good to mention here that accept-ext has been removed in (12.5.1), and accept-charset is deprecated in (12.5.2), if that is new to this spec. Editors: see URL and URL
Because it isn't required, nor is it widely implemented (if at all). We try not to make requirements that we know won't be honoured.
Because the header is information about the capabilities of the origin server, not other members of the request chain. Intermediaries can change (e.g., with proxy configuration). Note that a gateway (e.g., a CDN) is effectively acting as an origin server, so it can do this. The language in this section needs to be tweaked, however; there are a few instances of 'server' that should be 'origin server'.
field"... (13.1.5) leads me to believe that only clients can send If-Range. So how can there be a response with If-Range? It looks like the phrase 'to a request' was dropped somewhere between and now.
this is intentional, it ought to be explained. This is how multipart works; see . I don't think there's value in re-specifying it here.
As per the spec: ...
Because we avoid making existing servers that predate this spec non-compliant (unless there's a very good reason, such as security)
I think this is an issue. and we need graceful way to fall back to fallback. I do not believe that HTTP11REQUIRED and 421 response code are the right solution. I think it would be good to make this part of WebSockets over HTTP3 spec. edit: remove double negation -> I think that HTTP11REQUIRED and 421 response code are not the answer.
I agree the options we have today are not the right fit. This document could provide that and update RFC 8441.
The server could just close the stream with H3VERSIONFALLBACK. Is that not sufficient?
Perhaps for WebSockets, but there's a more general question here. When a client uses Extended CONNECT with an unknown protocol, what is the correct failure mode? There's no guarantee that HTTP/1.1 would support an arbitrary requested protocol, even if it might be more likely to work with WebSockets.
I'm not sure we need a general solution, because it isn't clear that we have a general problem. The answer here will depend on why the client is using this protocol in the first place. For example with MASQUE, the client will know which proxy to connect to thanks to out-of-band configuration, so the proxy operator is responsible for ensuring its HTTP servers are in sync with its config servers. For WebSocket on the other hand, the issue is that WebSockets were originally designed for h1 and there exist servers that are gradually deploying h2 or h3 for GET but don't yet support WebSocket there. For those, H3VERSIONFALLBACK should be sufficient.
That's nice in theory. We should still say what happens when the proxy operator makes a mistake.
Why is this specific to extended CONNECT then? A server operator could make a mistake and end up with some GET resources not working on h3 too, right?
The example I would use here is a server that supports masque on H3 and H2 CONNECT. If for some reason a proxy operator gets desyncd with the config that it may or may not be responsible for, then things could go wrong. In a scenario where version fallback to HTTP/1.1 is not desirable, articulating such an error is underspecified. Similarly for H2 and H3 websocket, telling client the resource is not available or the stream was reset with the fallback error code is misinformation.
The format is capable of capturing messages, but the design only really supports the expression of the semantics of valid messages. That makes it unsuitable for applications that need to know exactly what was put on the wire in a given protocol.
This document is going to be viewed by some as establishing the 'shape' of an HTTP message -- which is a good and perhaps necessary thing. However, some will be sad, because it doesn't suit some applications such as forensic preservation of messages, bot detection, debugging, faithful representation of HTTP/1, etc., due to transformations and loss of certain information (especially around headers). So it'd be good to set expectations early on (perhaps in the Introduction).
Good point. It's for semantics, not forensics and all that.
This came up during interop - A relay received a subscribe with start={g=RelativeNext/0 o=Absolute/0}. Since the relay had not received any objects, it defaulted largest to 0 and interpreted the subscribe as starting at {g=1, o=0}. When {g=0,o=0} arrived, it was not forwarded. But there's a reasonable interpretation that it should have forwarded treated this as the beginning of the next subscription. This is partially related to and maybe
If the subscriber wanted to get the largest group, it would have made request start = {g=RelativePrevious/0, o=None} .. This would have the interpretation that subscribe starts at {g=0, o=0} when {g=0, o=0} arrives. This would also work when {g=0, o=22} arrives. If my understanding of locations is correct, then the original request of {g=RelativeNext/0 o=Absolute/0} is incorrect for the answer being expected ..
I think it's reasonable to return 0,0 The subscriber uses RelativeNext if it doesn't want old data. If no data has been generated, then that requirement is still met.
But that's ambiguous. Since Group and Object IDs are zero-based, that response also describes the situation in which the relay has received the first object from the first group, which is clearly a different state. Can we solve this problem by specifying that both GroupID and Object ID are >= 1 of they exist, and 0 if they do not? This can be used to describe the situation in which the subscription is active but the publisher has not yet produced any objects.
Oh to clarify, the SUBSCRIBE_OK should return None/None as the latest group/object. The first OBJECT delivered would be 0/0. And yeah we could switch object/group to be 1-indexed instead of 0-indexed. None=0
Individual Comment: Agreed that in this particular case, the client was not really asking for what they wanted. The "Largest group/object" language comes from the draft, though, and I think it's ambiguous what it means to a relay that hasn't seen any objects.
My interpretation of the spirit of the draft is that 0/0 would be forwarded in this case if the client asked to start Next/0 (eg: there's a bug in my relay), but if so, we should make it clear in the draft how it's supposed to work.
Is this
I think I can see the intent with what's there, but the draft could use some editorial text clarifying what "next/0" means when subscribe OK was "no content available".
I thought we decided on call that we were not going to steal bits from the group id / object id to indicate meta data what is going on. After that call I was expecting to see some explicit flag for "no content available" if that is what needed to be sent.
After merging , Subscribe OK has the flag you are referring to: https://moq-URL I left this issue open because I think there's still some ambiguity that can be resolved with editorial text.
makes sense - thanks
NAME can you write some editorial text to clarify this if you have something in mind?
I tried to write some text, but I got confused. Ignoring object locations for a second and just focusing on groups, I think this is what we want, but I'm unsure how to define "current" when there are no objects: I think the simplest way to resolve this is to treat the next seen group ID as the "next" one and anything attempting to match only "current" matches either a) nothing or b) . I recognize that b) may be controversial in that we don't require unitary increase in group IDs. Practically I think subscribers should usually ask for [RelativePrev/0, None] (give me the current group if you know it or the next seen group if you don't). If we assume that the publisher only says "ContentExists: false" when it hasn't published anything, and relays only repeat this when they get it from publishers, then it's somewhat easier to assume that anything before "next" simply doesn't exist. I'm unsure if this covers publisher restart cases well enough though. There's also an asymmetry in this case in that there's no message to communicate how the relative requests were interpreted, as SUBSCRIBE_OK now does when the largest object is known.
but I'd prefer a better recommendation here than "educate your customers."
Suppose a site is hosted on a particular provider (or CDN, equally). The customer flips the DNS entry to point to a new provider. However, the old provider doesn't know that and might continue to serve traffic via ORIGIN + Secondary Certificates for requests that originally reach the provider via other DNS records. It's current industry practice to leave the old provider configured and hot during a transition to ensure the graceful cutover. However, the DNS record change is considered to be sufficent. We might want to recommend that servers periodically ensure the DNS record points to them before serving Secondary Certificates / ORIGIN references. I think this is Security Considerations prose, not protocol elements or requirements, however.
Reviewer: Marco Tiloca Review result: Ready with Nits Thanks for this document! I have found it very well written and I believe it's basically ready. Please, see below some minor comments and nits. Best, /Marco [X] [Section 1.2] As to "absolute-path", it is more precise to point to Section 4.1 of [HTTP]. Editors: URL [X] [Section 3] "HTTP does not place a predefined limit on the length of a request-line, as described in Section 2 of [HTTP]" This can better point to Section 2.3 of [HTTP]. Editors: URL [X] [Section 3.2] "A client MUST send a Host header field in all HTTP/1.1 request messages." This sentence can be expanded to point to Section 7.2 of [HTTP]. "... excluding any userinfo subcomponent and its "NAME delimiter ..." This should point to Section 4.2.4 of [HTTP]. Editors: URL [X] [Section 3.3] "Alternatively, it might be better to redirect the request to a safe resource that explains how to obtain a new client." Is "client" actually the intended word here? Or is it about using redirection to explain the client how to obtain something else (e.g. a proper authority component for a follow-up request) ? Editors: client is the intended word here: this case is only possible if the client sent an HTTP/0.9 or HTTP/1.0 request without a Host header field, which should not be in any deployed client since 1995. [X] [Section 7.1.2] I believe it's better for the reader if the last paragraph is split into 2 or 3 sentences Editors: [X] [Section 9.8] "When encountering an incomplete close, a client SHOULD treat as completed all requests for which it has received ..." Shouldn't this be about received responses? Or does it refer to the completion of the exchanges started by the mentioned requests? Editors: yes, it's about the completion of the exchanges. [X] [Appendix A] The first paragraph can better point to Section 5.6.1 of [HTTP]. Editors: URL The reference for "absolute-path" should be Section 4.1 of [HTTP]. Editors: URL
Long indeed. NAME - do you want to give that a try?
NAME the ABNF is not the source of truth; as discussed, it's the recommended generated form. We have prose in that we use to do things like explicitly allow LFs to be separators and folding to be performed. Given that there is confusion, interoperability issues and security issues around bare CRs, a clear requirement seems proportional - especially when the ABNF does not specify error handling. I could see an argument to downgrade the requirement relating to generation to a note that it's not allowed, and I could see broadening the language in semantics to say that CRLF and LF are also not allowed.
For field values (Semantics), we clarify that these are illegal to generate. For recipients, we can say that for error handling, rejecting or converting to SP is common. Not sure what else needs to be said in Messaging.
I think that the security aspect justifies a new requirement; how about "MUST either reject or remove; suggest replacing with SP"? I was thinking about outside the field values -- mostly in the request-line and status-line. That said, I agree it's much less of a concern there, and I'm OK with dropping it if you think it's not worth it. I'll update the PR if you think the above is workable.
s/MUST either reject or remove/MUST either reject or replace/ ...I guess. Yes, that sounds right to me; although there might be pusback on the MUST (me neutral). The part for Messaging I believe deserves a separate issue and discussion.
NAME I'll make a change note in Messaging. WRT Semantics, the adjacent text about folding effectively deals with LF and CRLF. If you want to go to the trouble of separating into two issues and two pull requests, feel free. I'd rather just get it closed.
/me looks - NAME it already is called out. Please re-review.
On my agenda for today.
opened for field values
Splitting the issue was king of intrusive, sorry for that. The changes for [Messaging] have been merged. For [Semantics] please see URL
Popular clients handle LF, CR, and CRLF as newlines. HTTP only defines CRLF. Previously: URL
To clarify, this is about the CRLF in the HTTP-message production.
Covered here: URL ... but I agree it could be more visible (e.g., in 3).
And clients also accept lone CR. It seems worth testing either that they reject (network error) or adding that.
NAME see - in situ, see URL I'm still not sure it's obvious enough to someone reading in isolation; thoughts?
NAME that text does not treat CR without LF as a newline, unless I'm missing something. That text even seems to suggest that CRCRLF would be a single newline, whereas I'm pretty sure it ends up being treated as two newlines.
NAME I'm pretty sure CR alone is not valid, because I remember such a discussion a few years ago by the time haproxy used to accept this, after which I removed support for this. CRCRLF could at best be considered as a CR at the end of a line, though normally it's not a valid character there. It may possibly be replaced by LWS though.
Just found it, its in RFC7230.5 : URL Although the line terminator for the start-line and header fields is the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR.
Right, I realize it's not valid, but I also know that clients nevertheless accept it, which is why I raised this.
All clients?
If they don't, they're not interoperable on the Web as we know it.
The Web as we know it does not contain any CR-only line-delimited protocol services other than those deliberately attempting response smuggling. The protocol specifically forbids bare CR as a line delimiter, since that is known to not be interoperable with the vast majority of protocol parsers that exclusively check for LF and ignore CR. This was a big deal in 1994, but even then it was obvious that CR-delimited messages wouldn't make it through proxies. Nobody has objected to it since OS X was released and the last of the native Mac servers disappeared. If some browsers interpret CR as a line delimiter in HTTP protocol fields (other than payload content), they have security holes that should be fixed. No change to the RFC is possible here; we can't make changes that introduce new security holes to previously compliant parsers.
I wrote some tests for this: URL Suggestions for more tests appreciated. Firefox seems to generally take the CR and include it in the value of whatever preceded it (reason phrase or header value, despite those not allowing this character).