What is the use of Subscribe and Unsubscribe commands in Imap4req1? I checked RFC 3501, but i could not understand its use. What will happen when i write following commands
A SUBSCRIBE "MAILBOX_NAME"
A UNSUBSCRIBE "MAILBOX_NAME"
will server treat those mailboxes as separate one?
Sample :
please check below once, and tell the difference
A LIST "" "*"
* LIST (\HasNoChildren) "/" "Bulk Mail"
* LIST (\HasNoChildren) "/" "Draft"
* LIST (\HasNoChildren) "/" "Inbox"
* LIST (\HasNoChildren) "/" "Sent"
* LIST (\HasNoChildren) "/" "Trash"
A OK LIST completed
A SUBSCRIBE INBOX
A OK SUBSCRIBE completed
A LSUB "" "*"
* LSUB (\HasNoChildren) "/" "Bulk Mail"
* LSUB (\HasNoChildren) "/" "Draft"
* LSUB (\HasNoChildren) "/" "Inbox"
* LSUB (\HasNoChildren) "/" "Sent"
* LSUB (\HasNoChildren) "/" "Trash"
A OK LSUB completed
They change the output of the LSUB command. That's it. SUBSCRIBE adds folders to the output of the LSUB command. UNSUBSCRIBE will remove them from the output of the LSUB command. That is, LSUB shows only subscribed folders.
LIST will always show all folders.
For example starting with all folders subscribed:
a LIST "" *
* LIST (\HasNoChildren) "." "INBOX.Drafts"
* LIST (\HasNoChildren) "." "INBOX.Sent"
* LIST (\HasNoChildren) "." "INBOX.Trash"
* LIST (\Marked \HasChildren) "." "INBOX"
a OK LIST completed
a LSUB "" *
* LSUB (\Marked \HasChildren) "." "INBOX"
* LSUB (\HasNoChildren) "." "INBOX.Drafts"
* LSUB (\HasNoChildren) "." "INBOX.Sent"
* LSUB (\HasNoChildren) "." "INBOX.Trash"
a OK LSUB completed
Now let's unsubscribe INBOX.Sent:
a UNSUBSCRIBE INBOX.Sent
a OK Folder unsubscribed.
a LSUB "" *
* LSUB (\Marked \HasChildren) "." "INBOX"
* LSUB (\HasNoChildren) "." "INBOX.Drafts"
* LSUB (\HasNoChildren) "." "INBOX.Trash"
a OK LSUB completed
All that's different is that INBOX.Sent has been removed from the LSUB output. Note that LIST output will not have been affected at all.
Now let's put it back:
a SUBSCRIBE INBOX.Sent
a OK Folder subscribed.
a LSUB "" *
* LSUB (\HasNoChildren) "." "INBOX.Sent"
* LSUB (\Marked \HasChildren) "." "INBOX"
* LSUB (\HasNoChildren) "." "INBOX.Drafts"
* LSUB (\HasNoChildren) "." "INBOX.Trash"
a OK LSUB completed
They are generally used for a client to mark folders the user is interested in seeing.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
https://www.example.com/&audience=testingting?internal-abhishek-jwt=random_string
Is this a valid URL? i.e is it fine to have &audience first and ?internal-abhishek-jwt as the second query paramter?
Please note audience has & as prefix
Is this a valid URL?
The URL spec says that the path should be expressed per these rules:
path = path-abempty ; begins with "/" or is empty
/ path-absolute ; begins with "/" but not "//"
/ path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment
/ path-empty ; zero characters
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0<pchar>
segment = *pchar
segment-nz = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "#" )
; non-zero-length segment without any colon ":"
pchar = unreserved / pct-encoded / sub-delims / ":" / "#"
Which, to cut a long story short, allows the types of character defined on the last line in a segment (which is where you want to put your &).
And if we look at sub-delims:
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
… so & is allowed.
That said, it is highly unusual to see a & in a URL outside of a query string.
If you put one there then it is not unlikely that someone transcribing the URL will assume you made a mistake and change it … thus breaking it.
So they are best avoided.
i.e is it fine to have &audience first and ?internal-abhishek-jwt as the second query paramter?
No.
The ? starts the query string. Putting them in that order makes &audience part of the path.
I'm using Chilkat.IMAP components to get emails from IMAP servers. If a mailbox name contains non-English symbols, "BAD Could not parse command" is returned:
----IMAP REQUEST----
aaai LIST "[Gmail]/" "%"
----IMAP RESPONSE----
* LIST (\All \HasNoChildren) "/" "[Gmail]/All Mail"
* LIST (\HasChildren \Trash) "/" "[Gmail]/Bin"
* LIST (\Drafts \HasNoChildren) "/" "[Gmail]/Drafts"
* LIST (\HasNoChildren \Important) "/" "[Gmail]/Important"
* LIST (\HasNoChildren \Sent) "/" "[Gmail]/Sent Mail"
* LIST (\HasNoChildren \Junk) "/" "[Gmail]/Spam"
* LIST (\HasNoChildren) "/" "[Gmail]/&BB8EMAQ,BDoEMA-"
aaai OK Success
----IMAP REQUEST----
aaaj LIST "[Gmail]/All Mail/" "%"
----IMAP RESPONSE----
aaaj OK Success
----IMAP REQUEST----
aaap LIST "[Gmail]/Папка/" "%"
----IMAP RESPONSE----
aaap BAD Could not parse command
IMAP by default does not send 8-bit characters, and the original protocol defines mailboxes with non-English ASCII characters to be UTF-7 encoded (with some modifications). This is the &BB8EMAQ,BDoEMA- you're seeing.
You can either add UTF-7 encoding/decoding to your application, or, if your server is new enough, ENABLE UTF-8 mode. Note: enabling UTF-8 may get you Unicode in places you do not expect. Gmail does support this extension.
> a LIST "" *
< ...
< * LIST (\HasChildren) "/" "&AOk-cole"
> b ENABLE UTF8=ACCEPT
< ...
< * LIST (\HasChildren) "/" "école"
Here's how that UTF-7 string breaks down:
[Gmail]/&BB8EMAQ,BDoEMA-
& and - shift in and out of decoding mode, so this looks like
"[Gmail]/" + mUTF7decode("BB8EMAQ,BDoEMA")
And here's a python 3 one liner that decodes that. With "===" added to meet the base64 padding requirements, and the altchars specifying the last two characters of the base64 encoding:
>>> import base64; base64.b64decode("BB8EMAQ,BDoEMA===", altchars="+,").decode("utf-16be")
'Папка'
It may be that you're using a very old version of Chilkat. Try the latest version, it should work fine. If not, please let us know..
I have an application that takes all the parameters in the url like this: /category/subcategory/sub-subcategory. I want to be able to give out extra parameters at the end of the URL, like page-2/order-desc. This would make the whole URL into cat/subcat/sub-subcat{delimiting-character}page-2/order-desc.
My question is: what characters could I use as {delimiting-character}. I tend to prefer ":" as I know for sure it will never appear anyplace else but I don't know if it would be standard compliant or at least if it will not give me problems in the future.
As I recall vimeo used something like this: vimeo.com/video:{code} but they seem to have changed this.
You can use alphanumeric, plus the special characters "$-_.+!*'(),"
More info here: http://www.ietf.org/rfc/rfc1738.txt
Also, take note not to exceed 2000 characters in url
The most recent URI spec is RFC 3986; see the ABNF for details on what characters are allowed in which parts for the URI.
The format for an absolute path part is:
path-absolute = "/" [ segment-nz *( "/" segment ) ]
segment = *pchar
segment-nz = 1*pchar
pchar = unreserved / pct-encoded / sub-delims / ":" / "#"
pct-encoded = "%" HEXDIG HEXDIG
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
See http://www.ietf.org/rfc/rfc1738.txt
Basically, you are allowed all aphanumerics as well as $ - _ . + ! * ' ( ) ,
If you use dash or underscore, remember that a dash is read by Google as a hyphen, so does not alter how your URL is categorized. An underscore is counted as a character, and can mess up your SEO.
Ex: dash-use = dash use (2 words);
underscore_use = underscore_use (1 word)
You could use a dash or an underscore (these are used frequently). You could use any character you want to but for example, spaces turn into %20 in the url so they don't look too-nice.
How do I extract the transaction receipt datetime with the least bit of noise in my parse rule from the following HTML? (The output I'm looking to get is this: "Transaction Receipt: 04/28/2011 17:03:09")
<FONT COLOR=DARKBLUE>Transaction Receipt </FONT></TH></TR><TR></TR><TR></TR><TR><TD COLSPAN=4 ALIGN=CENTER><FONT SIZE=-1 COLOR=DARKBLUE>04/28/2011 17:03:09</FONT>
The following works but I don't get a good feeling! There is guaranteed to be a datetime following the words Transaction Receipt somewhere (although I wouldn't do a greedy match if I'm doing a grep)
parse d [
thru {<FONT COLOR=DARKBLUE>Transaction Receipt </FONT></TH></TR><TR></TR><TR></TR><TR><TD COLSPAN=4 ALIGN=CENTER><FONT SIZE=-1 COLOR=DARKBLUE>}
copy t to "</FONT>"
]
This is shorter...
parse d [thru <FONT SIZE=-1 COLOR=DARKBLUE> copy t to </FONT>]
but isn't specifically looking for the datetime pair. And unfortunately REBOL considers the date used an invalid one...
>> 04/28/2011
** Syntax Error: Invalid date -- 04/28/2011
** Near: (line 1) 04/28/2011
so you can't search for it specifically. If the date was 28/04/2011 (and there was a space after the time, though why it's needed for load I'm not sure), the following would work...
parse load d [to date! copy t to </FONT>]
Hmmm. Try this...
t: ""
parse d [
some [
to "<" thru ">" mark: copy text to "<" (if text [append t text]) :mark
]
]
That returns: "Transaction Receipt 04/28/2011 17:03:09"
It works by skipping all the tags, appending any text that's left to t.
Hope that helps!
Timely as per usual: if the format is consistent, you can always try to explicitly match dates:
rule: use [dg tag date value][
tag: use [chars][
chars: charset [#"a" - #"z" #"A" - #"Z" #"0" - #"9" " =-"]
["<" opt "/" some chars ">"]
]
date: use [dg mo dy yr tm][
dg: charset "0123456789"
[
copy mo [2 dg "/"] copy dy [2 dg "/"] copy yr 4 dg
" " copy tm [2 dg ":" 2 dg ":" 2 dg]
(value: load rejoin [dy mo yr "/" tm])
]
]
[
some [
"Transaction Receipt" (probe "Transaction Receipt")
| date (probe value)
; everything else
| some " " | tag ; | skip ; will parse the whole doc...
]
]
]
Does anyone know the full list of characters that can be used within a GET without being encoded? At the moment I am using A-Z a-z and 0-9... but I am looking to find out the full list.
I am also interested into if there is a specification released for the up coming addition of Chinese, Arabic url's (as obviously that will have a big impact on my question)
EDIT: As #Jukka K. Korpela correctly points out, RFC 1738 was updated by RFC 3986.
This has expanded and clarified the characters valid for host, unfortunately it's not easily copied and pasted, but I'll do my best.
In first matched order:
host = IP-literal / IPv4address / reg-name
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
ls32 = ( h16 ":" h16 ) / IPv4address
; least-significant 32 bits of address
h16 = 1*4HEXDIG
; 16 bits of address represented in hexadecimal
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
reg-name = *( unreserved / pct-encoded / sub-delims )
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" <---This seems like a practical shortcut, most closely resembling original answer
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "#"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
pct-encoded = "%" HEXDIG HEXDIG
Original answer from RFC 1738 specification:
Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
reserved characters used for their reserved purposes may be used
unencoded within a URL.
^ obsolete since 1998.
The characters allowed in a URI are either reserved or unreserved (or a percent character as part of a percent-encoding)
http://en.wikipedia.org/wiki/Percent-encoding#Types_of_URI_characters
says these are RFC 3986 unreserved characters (sec. 2.3) as well as reserved characters (sec 2.2) if they need to retain their special meaning. And also a percent character as part of a percent-encoding.
The full list of the 66 unreserved characters is in RFC3986, here: https://www.rfc-editor.org/rfc/rfc3986#section-2.3
This is any character in the following regex set:
[A-Za-z0-9_.\-~]
I tested it by requesting my website (apache) with all available chars on my german keyboard as URL parameter:
http://example.com/?^1234567890ß´qwertzuiopü+asdfghjklöä#<yxcvbnm,.-°!"§$%&/()=? `QWERTZUIOPÜ*ASDFGHJKLÖÄ\'>YXCVBNM;:_²³{[]}\|µ#€~
These were not encoded:
^0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,.-!/()=?`*;:_{}[]\|~
Not encoded after urlencode():
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.-_
Not encoded after rawurlencode():
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.-_~
Note: Before PHP 5.3.0 rawurlencode() encoded ~ because of RFC 1738. But this was replaced by RFC 3986 so its safe to use, now. But I do not understand why for example {} are encoded through rawurlencode() because they are not mentioned in RFC 3986.
An additional test I made was regarding auto-linking in mail texts. I tested Mozilla Thunderbird, aol.com, outlook.com, gmail.com, gmx.de and yahoo.de and they fully linked URLs containing these chars:
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.-_~+#,%&=*;:#
Of course the ? was linked, too, but only if it was used once.
Some people would now suggest to use only the rawurlencode() chars, but did you ever hear that someone had problems to open these websites?
Asterisk
http://wayback.archive.org/web/*/http://google.com
Colon
https://en.wikipedia.org/wiki/Wikipedia:About
Plus
https://plus.google.com/+google
At sign, Colon, Comma and Exclamation mark
https://www.google.com/maps/place/USA/#36.2218457,...
Because of that these chars should be usable unencoded without problems. Of course you should not use &; because of encoding sequences like &. The same reason is valid for % as it used to encode chars in general. And = as it assigns a value to a parameter name.
Finally I would say its ok to use these unencoded:
0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.-_~!+,*:#
But if you expect randomly generated URLs you should not use punctuation marks like .!, because some mail apps will not auto-link them:
http://example.com/?foo=bar! < last char not linked
From here
Thus, only alphanumerics, the special characters $-_.+!*'(),
and reserved characters used for their
reserved purposes may be used unencoded within a URL.
RFC3986 defines two sets of characters you can use in a URI:
Reserved Characters: :/?#[]#!$&'()*+,;=
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "#"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
The purpose of reserved characters is to provide a set of delimiting characters that are distinguishable from other data within a URI. URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent.
Unreserved Characters: A-Za-z0-9-_.~
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
Characters that are allowed in a URI but do not have a reserved purpose are called unreserved.
These are listed in RFC3986. See the Collected ABNF for URI to see what is allowed where and the regex for parsing/validation.
This answer discusses characters may be included inside a URL fragment part without being escaped. I'm posting a separate answer since this part is slightly different than (and can be used in conjunction with) other excellent answers here.
The fragment part is not sent to the server and it is the characters that go after # in this example:
https://example.com/#STUFF-HERE
Specification
The relevant specifications in RFC 3986 are:
fragment = *( pchar / "/" / "?" )
pchar = unreserved / pct-encoded / sub-delims / ":" / "#"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
This also references rules in RFC 2234
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
Result
So the full list, excluding escapes (pct-encoded) are:
A-Z a-z 0-9 - . _ ~ ! $ & ' ( ) * + , ; = : # / ?
For your convenience here is a PCRE expression that matches a valid, unescaped fragment:
/^[A-Za-z0-9\-._~!$&'()*+,;=:#\/?]*$/
Encoding
Counting this up, there are:
26 + 26 + 10 + 19 = 81 code points
You could use base 81 to efficiently encode data here.
The upcoming change is for chinese, arabic domain names not URIs. The internationalised URIs are called IRIs and are defined in RFC 3987. However, having said that I'd recommend not doing this yourself but relying on an existing, tested library since there are lots of choices of URI encoding/decoding and what are considered safe by specification, versus what are safe by actual use (browsers).
If you like to give a special kind of experience to the users you could use pushState to bring a wide range of characters to the browser's url:
var u="";var tt=168;
for(var i=0; i< 250;i++){
var x = i+250*tt;
console.log(x);
var c = String.fromCharCode(x);
u+=c;
}
history.pushState({},"",250*tt+u);