Are "http://Example.com" and "http://example.com:80" the same origin, like MDN states? - same-origin-policy

In the MDN definition of Origin (https://developer.mozilla.org/en-US/docs/Glossary/Origin)
there is a section with examples (https://developer.mozilla.org/en-US/docs/Glossary/Origin#examples)
the second example is stating that:
These are same origin because a server delivers HTTP content through port 80 by default:
http://Example.com:80
http://example.com
Now, there are two things to notice:
maybe there is a typo, but the first URL is "Example" with uppercase 'E' and the second URL is "example" with lowercase 'e'. Are they really considered to be the same origin? Is origin case-insensitive?
Apart from the difference of uppercase "E" and "e", are they really the same origin, if the first has "explicit" port 80 and the second has implicit port 80? Is MDN correct or it is wrong?
I'm starting to though that the solution is in the middle: MDN is correct and they are the same "origin". Still, a modern browser will block a request from the first to the second due to the same-origin-policy because the browser doesn't check if they are the same "origin", but only check if they are the same "character sequence", and obviously they aren't. Is this interpretation true?

Related

How to maintain the escaped quotes in an expression in Spring Cloud Data Flow?

When I configure my stream to be depoyed, in which I'm using a processor (transform, script or http-request), in the "expression" atribute I need to set an expression that contains quotes and double quotes (escaped). The expression works properly the first time I set and allows to deploy the stream, but if I undeploy the stream and try again to deploy it, the spring cloud data flow throws state machine exception because the backslashes used to escape the double quotes are removed.
I already follow the considerations in the Spaces and Quotes documentation, but I think that it only applies to the streams definition and not to the deployment time.
The URL of the spaces and quotes documentarion is: https://docs.spring.io/spring-cloud-dataflow/docs/current-SNAPSHOT/reference/htmlsingle/#shell-white-space
And the sample of the type of expression required:
expression="new String('{\"size\": 1,\"sort\": {\"timestamp\": \"desc\"},\"query\": {\"prefix\": {\"integrationname\": \"63320e0d313862934667225f\"}}}')"
The stream could be as simple as:
http | transform | log
The firs time the expression is set looks like as follows:
expression="new String('{\"size\": 1,\"sort\": {\"timestamp\": \"desc\"},\"query\": {\"prefix\": {\"integrationname\": \"63320e0d313862934667225f\"}}}')"
Deploying correctly the stream.
Once the stream is undeployed and try to deploy it again, the espression looks like:
expression="new String('{"size": 1,"sort\": {"timestamp": "desc"},"query": {"prefix": {"integrationname": "63320e0d313862934667225f"}}}')"
Where the backslashes were removed, causing the state machine exception because of the unescaped double quotes.
Thanks in advance
We are looking at Issue #5145 and will update the issue when we have fixed it.
In the meantime I would suggest using the spring-cloud-dataflow-shell or the REST API to automate deployments where you provide the properties every time as needed.

invalid URL escape "%" when docker push

I set up a registry at docker-registry.elektron.space and when I want to push an image with $ docker push docker-registry.elektron.space/boxbeat-media-server, the upload animation is running in loop for each entity passing from "Pushing" state to "Retrying in X seconds".
After a while I get this error:
failed to parse Location header "https://docker-registry.elektron.space/v2/boxbeat-media-server/blobs/uploads/56244149-c196-439a-85bf-af1121e0b84b%?_state=h1lqY-NljkLbgzTCjd8jxcfdscojPHApblWu-45ISK57Ik5hbWUiOiJib3hiZWF0LW1lZGlhLXNlcnZlciIsIlVVSUQiOiI1NjI0NDE0OS1jMTk2LTQzOWEtODViZi1hZjExMjFlMGI4NGIiLCJPZmZzZXQiOjAsIlN0YXJ0ZWRBdCI6IjIwMjAtMDMtMDFUMTU6MzI6NTAuMzcxNjc5NTc5WiJ9": parse https://docker-registry.elektron.space/v2/boxbeat-media-server/blobs/uploads/56244149-c196-439a-85bf-af1121e0b84b%?_state=h1lqY-NljkLbgzTCjd8jxcfdscojPHApblWu-45ISK57Ik5hbWUiOiJib3hiZWF0LW1lZGlhLXNlcnZlciIsIlVVSUQiOiI1NjI0NDE0OS1jMTk2LTQzOWEtODViZi1hZjExMjFlMGI4NGIiLCJPZmZzZXQiOjAsIlN0YXJ0ZWRBdCI6IjIwMjAtMDMtMDFUMTU6MzI6NTAuMzcxNjc5NTc5WiJ9: invalid URL escape "%"
In a readable way:
failed to parse Location header
"https://docker-registry.elektron.space/v2/boxbeat-media-server/blobs/uploads/
56244149-c196-439a-85bf-af1121e0b84b%?_state=
h1lqY-NljkLbgzTCjd8jxcfdscojPHApblWu-45ISK57Ik5hbWUiOiJib3hiZWF0LW1lZGlhLXNlcnZlciIsIlVVSUQiOiI1NjI0NDE0OS1jMTk2LTQzOWEtODViZi1hZjExMjFlMGI4NGIiLCJPZmZzZXQiOjAsIlN0YXJ0ZWRBdCI6IjIwMjAtMDMtMDFUMTU6MzI6NTAuMzcxNjc5NTc5WiJ9":
parse https://docker-registry.elektron.space/v2/boxbeat-media-server/blobs/uploads/
56244149-c196-439a-85bf-af1121e0b84b%?_state=
h1lqY-NljkLbgzTCjd8jxcfdscojPHApblWu-45ISK57Ik5hbWUiOiJib3hiZWF0LW1lZGlhLXNlcnZlciIsIlVVSUQiOiI1NjI0NDE0OS1jMTk2LTQzOWEtODViZi1hZjExMjFlMGI4NGIiLCJPZmZzZXQiOjAsIlN0YXJ0ZWRBdCI6IjIwMjAtMDMtMDFUMTU6MzI6NTAuMzcxNjc5NTc5WiJ9:
invalid URL escape "%"
Where does this "%" come from? I thought this could come from zsh then I tried to run it with bash but same result.
Any idea?
The issue is that a % sign is used to initiate an escape sequence in url encoding. You need to escape the % itself.
So in your case you should replace the % with %25 which is the escaped form if it. That way you don't get the error because the parser doesn't think an escape sequence is about to start when it sees the %
... /uploads/56244149-c196-439a-85bf-af1121e0b84b%25 ...
This article can also help to understand things better. Even though its about javascript, the information is applicable much broader.
You can lookup escape sequences on this page.

What field does the Docker tag relate to in RFC 5424

My Docker syslog tags are being truncated at what seems to be 32 characters. When I look at RFC 5424 I am not sure which field it is. Anyone know? I am trying to verify the allowed length the tag can be.
Apr 19 06:43:05 ord-nodecore-prd-01 docker/core_sql_event_processor_ha[1207]: 2016-04-19T06:43:05.265Z [sqlEventHandler] Event '3c5e1a15-f8a1-4bfa-b2fa-2e54b2a5fbaa' resulted in 0 relevant application events
Becomes:
<30>Apr 19 06:43:05 ord-nodecore-prd-01 docker/core_sql_event_processor_ 2016-04-19T06:43:05.265Z [sqlEventHandler] Event '3c5e1a15-f8a1-4bfa-b2fa-2e54b2a5fbaa' resulted in 0 relevant application events
Note the tag, docker/core_sql_event_processor_ha[1207]:
Here is the RFC link: https://www.rfc-editor.org/rfc/rfc5424#page-9
I am thinking it is the 'SD-Name' but it may be 'APP-Name'. No idea.
Your example has nothing to do with RFC5424, and looks more like RFC3164 (which is not a standard, but a collection of older best practices).
Please read this: https://www.rfc-editor.org/rfc/rfc5424#appendix-A.1
then search for 'TAG ' - in essence, RFC5424 does not have a TAG field as such.
I am not familiar with Docker logging, but if I read
https://docs.docker.com/engine/admin/logging/overview/#syslog-options
, then check syslog-format - it seems that the format can be specified, also to be like rfc5424micro which I would recommend, but seems like in your case it is not configured like that.

What does exactly *.* mean when used in IMAP command?

I know that using * in IMAP FETCH Command either defines all or one mail but does
"*:*" also defines all mails in the selected folder? Does it defines something else too? Asking cause my company is implementing its own IMAP server, and I couldn't find any reference to *:* in the RFC 3501 and 4466.
If possible, please also cite the RFC.
* does not mean all mail. As a number, * means "the last message in the folder". More generally, 42 means "message 42", 42:50 means "messages 42 to 50 inclusive", 42:* "messages 42 to the last one", and * means "the last message", see? *:* is another way to say "just the last message".
But *.* doesn't mean anything in particular. I can't think of any case where that is even syntactically valid.
: would mean just the last message. You can check for rfc 791. Check www.tools.ietf.org

About the return values of the telnet server on windows xp

I am writing a telnet proxy on xp. Now I can telnet to system's telnet server and print its return values sending back to my procedure.
I find a very puzzling phenomenon. When I first telnet to the server,it will ask me to log in. I type in "tamlok", and I can see that it sending back to me that "116,97,109,108,111,107,10,13" which is the ascii value of "tamlok"(10 and 13 means '\n' and '\r').
However after I log in,I type in "tamlok" again. It sends back to me that "27,91,56,59,51,52,72,116,0,97,0,108,0,111,0,107,0,27,91,57,59,49,72".
I suggest that it returns the unicode so that "116" turns into "116,0" and so on. But I can't understand the sequence "27,91,56,59,51,52,72" and "27,91,57,59,49,72". I think it maybe a sequence for a special function, just like {0x1B, 0x5B, 0x48, 0x1B, 0x5B, 0x4A} will clear the console.
So,how to interpret this?
Any help is welcome!
Thanks to Joachim Pileborg.Now it is clear that it is terminal control codes. An example.
So "27,91,56,59,51,52,72" is "[Esc][8;34H" which suits the pattern:
Cursor Home [{ROW};{COLUMN}H
Sets the cursor position where subsequent text will begin. If no row/column parameters are provided (ie. [H), the cursor will move to the home position, at the upper left of the screen.
So does 27,91,57,59,49,72".

Resources