24 Matching Annotations
  1. Aug 2024
  2. Nov 2023
    1. 或許是受「忠於原著」的說法影響,很多中譯者都十分規行矩步,處理長句子時會乖乖按著子句順序來譯,就算譯出來怪怪的,也很少作出大刀闊斧的改動。這樣直譯的結果,往往是讀者的惡夢。

      此文旨在批評「直譯」是不佳的做法,但所舉三例中,較差的二例,並非是直譯造成的問題,而原po的翻譯較好,也並非因爲不直譯,其實,從句法看,直譯的程度:

      張 > 毫末 > 宋

      宋是最大程度打破原文的語法重新組織,但恰好也寫出最拗口賣弄的中文。

  3. Sep 2022
    1. The server possibly can send back a 406 (Not Acceptable) error code when unable to serve content in a matching language. However, such a behavior is rarely implemented for a better user experience, and servers often ignore the Accept-Language header in such cases.
  4. Jan 2022
    1. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.

      Meaning that 99% of the people use it are using it "wrong" because they're not using it for HTTP authentication and don't send a WWW-Authenticate header field with their 401 response?

      Hmm. That's a tough one. On the one hand, the spec does say they must send it.

      Initial opinion

      But on the other hand, one could argue that that requirement only applies if using 401 for HTTP authentication. And that saying it's wrong to do so (as they claim at https://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses/14713094#14713094 and https://hyp.is/JA45zHotEeybDdM_In4frQ/stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses) is having a too strict/narrow/literal interpretation.

      HTTP is meant to be used widely in many very different uses and contexts, most of which do not use this very specific HTTP authentication scheme; my opinion is that they shouldn't be denied from using it, just because they don't have anything useful WWW-Authenticate header field. (Or (which is also fine with me), just put something "emptyish" in the field, like "Unused". Unless that would trigger a Basic auth modal in the browser, in which case we shouldn't, for practical reasons.)

      Why shouldn't we be able to repurpose this same status code for uses that are still authentication, but just not HTTP authentication per se?

      Is it really wrong to repurpose this useful status code for other contexts, like cookie-based app-defined authentication systems?

      I say that it's okay to repurpose/reuse 401 for any authentication system (that uses HTTP as a part of it, even though not using HTTP's own authentication system), as long as we try to maintain the same semantic as originally intended/described here. I think it's okay to use 401 as a response to a XHR request, and then have the client redirect to a login page, which provides a way to authenticate again (reattempt the authentication challenge), analogous to how it works for HTTP authentication.

      Revised opinion

      https://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses/14713094#14713094 has made me change my mind and convinced me that...

      Authentication by schemes outside of (not defined by) RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication should not use HTTP status 401, because 401 Unauthorized is only defined (by current RFCs) by RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication, and has semantics and requirements (such as the requirement that "A server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field containing at least one challenge.") that simply don't make sense or cannot be fulfilled if using a non-HTTP authentication scheme.

      403 Forbidden, on the other hand, is defined by the broader HTTP standard, in RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content and RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication.

      In conclusion, if you have your own roll-your-own login process and never use HTTP Authentication, 403 is always the proper response and 401 should never be used.

      Couldn't a custom auth system use WWW-Authenticate header?

      The question was asked:

      Doesn't RFC7235 provide for "roll-your-own" or alternate auth challenges? Why can't my app's login flow present its challenge in the form of a WWW-Authenticate header? Even if a browser doesn't support it, my React app can...

      And I would say sure, if you want (and if the browser doesn't automatically show a Basic auth modal in this case and thwart your plans).

      They might be on to something here with that question!

      But that should probably be the test of whether you can/should use 401: are you actually using WWW-Authenticate header?

      Indeed I found an example where it is used for OAuth2.

    1. Authentication by schemes outside of RFC2617 is not supported in HTTP status codes and are not considered when deciding whether to use 401 or 403.

      What does "are not considered when deciding whether to use 401 or 403" mean exactly? What exactly should not be considered, and what exactly should be considered instead? In other words, how did someone arrive at the conclusion that "if you have your own roll-your-own login process and never use HTTP Authentication, 403 is always the proper response and 401 should never be used."? Why is 403 okay to use for non-HTTP authentication, but not 401?

      Oh, I think I understand the difference now.

      They should have said:

      Authentication by schemes outside of (not defined by) RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication should not use HTTP status 401, because 401 Unauthorized is only defined (by current RFCs) by RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication, and has semantics and requirements (such as the requirement that "A server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field containing at least one challenge.") that simply don't make sense or cannot be fulfilled if using a non-HTTP authentication scheme.

      403 Forbidden, on the other hand, is defined by the broader HTTP standard, in RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content and RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication.

      In conclusion, if you have your own roll-your-own login process and never use HTTP Authentication, 403 is always the proper response and 401 should never be used.

      See also my comments in https://hyp.is/p1iCnnowEeyUPl9PxO8BuQ/www.rfc-editor.org/rfc/rfc7235

    2. The statement is "If the request already included Authorization credentials". That means if this is a response from a request which provided the credential (e.g. the response from a RFC2617 Authentication attempt). It is essentially to allow the server to say, "Bad account/password pair, try again". In the posed question, the user is presumably authenticated but not authorized. 401 is never the appropriate response for those circumstances.
    3. 401 is only appropriate for HTTP Authentication
  5. Nov 2021
    1. Object literals don't have index signatures. They are assignable to types with index signatures if they have compatible properties and are fresh (i.e. provably do not have properties we don't know about) but never have index signatures implicitly or explicitly.
  6. Sep 2021
  7. Apr 2021
  8. Feb 2021
    1. For the usage in society, see Second-class citizen.
      1. Ironic that this reference is ostensibly about the usage of "first-class citizen" in society, yet it links to a seemingly-mismatched (by name only, that is) article, entitled "second-class citizen".

      2. Ironic that the first-class (unqualified) article is about the figurative meaning of "citizen" used in computer science, and that the page describing first-class and second-class status of the more literal citizens in society is relegated to what I kind of think is a second-class position in the encyclopedia (because it takes the #2 position numerically, even though it is (at least as is implied in this reference) also about first-class citizens (though the word "first-class" does not appear a single time in that article, so maybe this reference is the one that is more ironic/incorrect).

  9. Oct 2020
  10. Aug 2020
    1. I don't doubt that we will soon treat the process of logging in as a figurative point of entry, meaning that log into will make full conceptual sense (cf you don't physically delve into a problem or pile into an argument, yet both are correct grammatically because they are semantically [i.e. figuratively])
  11. Jul 2020
  12. idioms.thefreedictionary.com idioms.thefreedictionary.com
    1. Literally, an arcade game in which the player uses a small rubber mallet to hit robotic toy moles that pop up randomly in holes laid out across the surface of the machine.
  13. Jun 2020
    1. Money is moved from one place to another without a paper trail.

      Only in the literal sense. There's still an electronic paper trail, silly.

  14. May 2020
  15. Apr 2020
  16. Apr 2015
    1. Outside the triple, information is lost and a literal is just data without any meaning.

      That does seem to be a problem.

    2. hey can not be subjects in RDF triples – they are always the objects used to describe a resource.