Server to Client server responses

Hello all,
   So now we have the client to server part down we need to decide the  
server to client. How will we notify the client for success/fail and we  
need to develop it in such a way that future "extensions" can add to it.
For fail conditions we should send the standard 401 Unauthorized http  
response with the body being a message for the user using Content-Type:  
text/plain.
For success conditions we send the standard 200 OK http response with the  
body being plain text content type like the error condition but encoded in  
such a way the client can parse it easily. Some options are:
    1. urlencoded name=value pairs like the query string.
    2. JSON encoded objects

Personally I like 1.

Let me know what everyone thinks.

-- 
  -Dave
0
Dave
10/12/2013 3:45:46 AM
grc.sqrl 459 articles. 0 followers. Follow

15 Replies
945 Views

Similar Articles

[PageSpeed] 14

[for the unabridged version, see Dave Akers's post above]

> Hello all,
>    So now we have the client to server part down we need to
> decide the server to client. How will we notify the client for
> success/fail and we need to develop it in such a way that future
> "extensions" can add to it.

Right.

> For fail conditions we should send the standard 401 Unauthorized
> http response with the body being a message for the user using
> Content-Type: text/plain.

I don't think I'm a fan of attempting to reuse existing HTTP 
error codes for our purpose... if for no other reason than we 
have too much to convey.  For example, a 401 Unauthorized is
not really what we mean, and the system now has multiple types 
of "failure" and "success", and a lot that we may want to 
communicate back to the user: Signature Failure, User ID 
Unknown, IP-mismatch, User ID Unknown AND IP-mismatch, IP-match, 
Stale Nut, Invalid Nut... and so on.

I think we're better served if the standard HTTP error code is 
used to convey the success or failure of the underlying query 
transaction made by the client to the server:

200 OK - regardless of anything else, query received and reply 
with results sent.

I think anything else results in the UI saying that the server 
did not respond to our login request.

I don't THINK we want to behave like a full web browser and 
follow redirection replies?

So I think either we made contact with the authentication server 
and correctly received its results -- whatever they were -- or 
not.  And if not we explain to the user and ask whether they 
might wish to retry clicking the URL, rescanning the SQRL code, 
refreshing the original login page, etc.

Otherwise...

> For success conditions we send the standard 200 OK http response
> with the body being plain text content type like the error
> condition but encoded in such a way the client can parse it
> easily. Some options are:
>     1. urlencoded name=value pairs like the query string.
>     2. JSON encoded objects
> 
> Personally I like 1.

I do too, very much.  It's fast, easy, minimal and sufficient.

Working from just the ad-hoc thoughts I posted above, suppose we 
have four variables 'result', 'reason', 'detail', and 'link' and 
that each of them, if present, can have ONE OR MORE comma-
separated values, such as:

result={success}
       {failure}

reason={invalidnut}
       {stalenut}
       {badformat}
       {badsig}
       {badscheme}
       {ipnomatch}
       {ipmatch}

detail={newuser}
       {olduser}

link={url of logged on session}

Although I like the idea of each of those appearing on its own 
line, I think we avoid confusion about line endings and such if 
we join them with '&' like a standard url-encoded name=value 
pair list.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
10/12/2013 4:56:57 PM
On Sat, 12 Oct 2013 11:56:57 -0500, Steve Gibson <news007_@_grc.com> wrote:

> I don't think I'm a fan of attempting to reuse existing HTTP
> error codes for our purpose... if for no other reason than we
> have too much to convey.  For example, a 401 Unauthorized is
> not really what we mean, and the system now has multiple types
> of "failure" and "success", and a lot that we may want to
> communicate back to the user: Signature Failure, User ID
> Unknown, IP-mismatch, User ID Unknown AND IP-mismatch, IP-match,
> Stale Nut, Invalid Nut... and so on.
>
> I think we're better served if the standard HTTP error code is
> used to convey the success or failure of the underlying query
> transaction made by the client to the server:
>
> 200 OK - regardless of anything else, query received and reply
> with results sent.
>
> I think anything else results in the UI saying that the server
> did not respond to our login request.
>
> I don't THINK we want to behave like a full web browser and
> follow redirection replies?

I agree here. The server is generating the sqrl link and should know where  
the link points to so there shouldn't be a reason for the server to send a  
redirection reply. Just about the only reason I use redirection replies is  
to bounce the user to https. In the case of SQRL if the server decided to  
use https it should fail the http request to let the client know it's  
doing something wrong.

>> For success conditions we send the standard 200 OK http response
>> with the body being plain text content type like the error
>> condition but encoded in such a way the client can parse it
>> easily. Some options are:
>>     1. urlencoded name=value pairs like the query string.
>>     2. JSON encoded objects
>>
>> Personally I like 1.
>
> I do too, very much.  It's fast, easy, minimal and sufficient.
>
> Working from just the ad-hoc thoughts I posted above, suppose we
> have four variables 'result', 'reason', 'detail', and 'link' and
> that each of them, if present, can have ONE OR MORE comma-
> separated values, such as:
>
> result={success}
>        {failure}
>
> reason={invalidnut}
>        {stalenut}
>        {badformat}
>        {badsig}
>        {badscheme}
>        {ipnomatch}
>        {ipmatch}
>
> detail={newuser}
>        {olduser}
>
> link={url of logged on session}
>

I think we should still have an error value with a user readable string to  
be shown to the user in the event the client doesn't understand the reason  
value. for example if the reason values were updated in 1.1 and it's a 1.0  
client connecting. The client could then display the error to the user and  
then the user could under stand the error condition even if the client  
does not.


-- 
  -Dave
0
Dave
10/12/2013 6:10:11 PM
Dave Akers wrote:

> I think we should still have an error value with a user readable string to
> be shown to the user in the event the client doesn't understand the reason
> value. for example if the reason values were updated in 1.1 and it's a 1.0
> client connecting. The client could then display the error to the user and
> then the user could under stand the error condition even if the client
> does not.

I think it's up to the client to know that its version is outdated, as we 
have the sqrlver parameter in the url. Also, if it receives some field or 
value it doesn't expect, it knows it's outdated.

I like to avoid using fields with arbitrary values as much as possible :)
0
Conrado
10/12/2013 7:10:17 PM
On Sat, 12 Oct 2013 14:10:17 -0500, Conrado Miranda <not@valid.email>  
wrote:

> Dave Akers wrote:
>
>> I think we should still have an error value with a user readable string  
>> to
>> be shown to the user in the event the client doesn't understand the  
>> reason
>> value. for example if the reason values were updated in 1.1 and it's a  
>> 1.0
>> client connecting. The client could then display the error to the user  
>> and
>> then the user could under stand the error condition even if the client
>> does not.
>
> I think it's up to the client to know that its version is outdated, as we
> have the sqrlver parameter in the url. Also, if it receives some field or
> value it doesn't expect, it knows it's outdated.
>
> I like to avoid using fields with arbitrary values as much as possible :)

The sqrlver in the url is from the client. the only thing the server puts  
in the url is the encrypted nut. So the client won't know the servers  
version.
I was just thinking about backwards compatibility.
Another way to do this would be to have the server handle the old version  
requests. and/or add to the reason a reason code to signal to the client  
it needs to update.
It'd be nice to have the ability to communicate to the user a more  
meaningful reason besides just the fail reason. If there is an error on  
the server side that there isn't an error reason code defined for is one  
example.

Some example messages:
   "Down for maintince"
   "Database offline"
   "User banned"
   "Quantum entanglement failure"

-- 
  -Dave
0
Dave
10/12/2013 7:43:33 PM
[for the unabridged version, see Dave Akers's post above]

> It'd be nice to have the ability to communicate to the user a
> more meaningful reason besides just the fail reason. If there
> is an error on the server side that there isn't an error reason
> code defined for is one example.
> 
> Some example messages:
>    "Down for maintince"
>    "Database offline"
>    "User banned"
>    "Quantum entanglement failure"

I agree. I think that's a great idea.

And I think that client behavior should be: If the parameter is 
present and not null, the text SHOULD be displayed to the user.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
10/12/2013 8:09:24 PM
In article <MPG.2cc31f2ffcf424aa3a5c@4.79.142.203>, news007_@_grc.com 
says...
> 
> Working from just the ad-hoc thoughts I posted above, suppose we 
> have four variables 'result', 'reason', 'detail', and 'link' and 
> that each of them, if present, can have ONE OR MORE comma-
> separated values, such as:
> 
> result={success}
>        {failure}
> 
> reason={invalidnut}
>        {stalenut}
>        {badformat}
>        {badsig}
>        {badscheme}
>        {ipnomatch}
>        {ipmatch}
> 
> detail={newuser}
>        {olduser}
> 
> link={url of logged on session}
> 

How much error information is too much?  In particular, some of the 
values described for reason and detail seem in direct conflict with 
CWE-209: Information Exposure Through an Error Message. 
http://cwe.mitre.org/data/definitions/209.html

Things like badformat don't leak internal state.  Things like stalenut, 
ipnomatch, and [new|old]user do.  In fact, revelation of [new|old]user to 
the client is itself a CVE in at least one case that I found.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1579

I realize that the user needs to be provided with some kind of error.  
Snapping away at a QRCode and getting back a new login screen would be 
completely opaque and frustrating and I'm not recommending that.  On the 
other hand, I work in compliance environments a lot and I'd have a hard 
time selling a security control that directly matched a CWE which would 
trigger an audit finding in any other context.  The examples tossed 
around in discussion include many sites that would be subject to 
compliance so I do not believe this objection to be an edge case. 

If we think some specific standard security practices do not apply to 
SQRL (it is a novel approach after all) then articulating why that is so 
provides a starting point for a discussion with the compliance bodies to 
update their standards.  It would be great to have a link to point people 
at which explained why internal server state exposed in error messages 
does not pose a risk if we think that's true.  Where we think standard 
security practices do apply, SQRL should make an effort to avoid known 
vulnerabilities listed by CWE, OWASP, NIST, etc.

Was all that server state in the error messages an oversight or because 
the SQRL architecture mitigates that risk?

-- T.Rob

0
T
10/12/2013 8:54:53 PM
Steve Gibson wrote:
>
> I don't think I'm a fan of attempting to reuse existing HTTP
> error codes for our purpose... if for no other reason than we
> have too much to convey.  For example, a 401 Unauthorized is
> not really what we mean, and the system now has multiple types
> of "failure" and "success", and a lot that we may want to
> communicate back to the user: Signature Failure, User ID
> Unknown, IP-mismatch, User ID Unknown AND IP-mismatch, IP-match,
> Stale Nut, Invalid Nut... and so on.
>

Do we actually want to convey a detailed reason back to the client, or 
should we just have "login failed". Telling the client exactly what is wrong 
helps them try again and makes it easier to hack.

AlanD

0
AlanD
10/12/2013 9:04:05 PM
[for the unabridged version, see AlanD's post above]

> Do we actually want to convey a detailed reason back to the
> client, or should we just have "login failed". Telling the
> client exactly what is wrong helps them try again and makes
> it easier to hack.

I see your point Alan. But no protocol that relies upon the 
attacker NOT knowing the reason for their failure would be 
secure anyway. As you know, the key to security is to rely
upon one very well protected secret, rather than on anything
that an attacker could poke at and/or guess.

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
10/12/2013 9:20:38 PM
[for the unabridged version, see T.Rob's post above]

T.Rob...

My reply to AlanD, which I wrote before reading your note, 
applies, I think, to your note too.

Though I do see your point.  My list provides more feedback
than is needed for the UI... and there's no point in that.

I was doing that so that the UI could suggest what course
of action should be taken, but we can make that explicit:

> result={olduser}    // authenticated a known existing user
>        {newuser}    // authenticated a new and unknown user
>        {failure}    // unspecified failure to authenticate

> ipmatch={yes}       // issued and query IPs match
>         {no}        // issued and query IPs do NOT match

> error={hard}        // retrying authentication won't help
>       {soft}        // retrying, refreshing, etc. might help

> link={url of logged on session}

> message={this is text to display to the user if present}

-- 
________________________________________________________________
Steve.               Working on moving the SQRL project forward.
0
Steve
10/12/2013 9:35:39 PM
In article <l3cdg5$2qls$1@news.grc.com>, AlanD says...
> 
> Steve Gibson wrote:
> >
> > I don't think I'm a fan of attempting to reuse existing HTTP
> > error codes for our purpose... if for no other reason than we
> > have too much to convey.  For example, a 401 Unauthorized is
> > not really what we mean, and the system now has multiple types
> > of "failure" and "success", and a lot that we may want to
> > communicate back to the user: Signature Failure, User ID
> > Unknown, IP-mismatch, User ID Unknown AND IP-mismatch, IP-match,
> > Stale Nut, Invalid Nut... and so on.
> >
> 
> Do we actually want to convey a detailed reason back to the client, or 
> should we just have "login failed". Telling the client exactly what is wrong 
> helps them try again and makes it easier to hack.
> 
> AlanD

Personally, I expect high-value websites to have an alternate means to login, 
i.e., userid/password/question.  After authenticating myself via the alternate 
means, having a page on that website that I could use to safely/securely test 
my SQRL processing would be extremely helpful in diagnosing my failure to login 
using SQRL.  Then I could take appropriate steps to comply with the 
requirements.  I know this is not part of the requirements, but it could be a 
suggested help for the website users.
0
Darrell
10/13/2013 1:36:27 AM
In message <l3cdg5$2qls$1@news.grc.com> 
  AlanD <nospam@danburyonline.net> wrote:
> Steve Gibson wrote:
>>
>> I don't think I'm a fan of attempting to reuse existing HTTP
>> error codes for our purpose... if for no other reason than we
>> have too much to convey.  For example, a 401 Unauthorized is
>> not really what we mean, and the system now has multiple types
>> of "failure" and "success", and a lot that we may want to
>> communicate back to the user: Signature Failure, User ID
>> Unknown, IP-mismatch, User ID Unknown AND IP-mismatch, IP-match,
>> Stale Nut, Invalid Nut... and so on.
>>

> Do we actually want to convey a detailed reason back to the client, 

We want to leave that up to the server, no?

>or should we just have "login failed". Telling the client exactly what
>is wrong helps them try again and makes it easier to hack.

A server may want to have a login failure degrade to a user/pass login
after several attempts (much like Apple's TouchID).


-- 
Standing on the moon with nothing else to do
A lovely view of heaven but I'd rather be with you
0
Lewis
10/13/2013 2:43:40 AM
On 2013-10-12 9:56 AM, Steve Gibson wrote:
> [for the unabridged version, see Dave Akers's post above]
>
>> Hello all,
>>     So now we have the client to server part down we need to
>> decide the server to client. How will we notify the client for
>> success/fail and we need to develop it in such a way that future
>> "extensions" can add to it.
>
> Right.
>
>> For fail conditions we should send the standard 401 Unauthorized
>> http response with the body being a message for the user using
>> Content-Type: text/plain.
>
> I don't think I'm a fan of attempting to reuse existing HTTP
> error codes for our purpose... if for no other reason than we
> have too much to convey.  For example, a 401 Unauthorized is
> not really what we mean, and the system now has multiple types
> of "failure" and "success", and a lot that we may want to
> communicate back to the user: Signature Failure, User ID
> Unknown, IP-mismatch, User ID Unknown AND IP-mismatch, IP-match,
> Stale Nut, Invalid Nut... and so on.

My inclination is in the opposite direction. HTTP responses can include 
headers, and any additional information we may wish to convey is 
probably well-suited to a header.

The reason my inclination is in the opposite direction, though, is that 
it looks like it would be very easy to design SQRL to be a drop-in 
replacement/supplement for HTTP Digest authentication. Making that work 
wouldn't require adoption within the HTTP spec, just a RFC and a 
"challenge" syntax that can be placed into the WWW-Authenticate header.

Making SQRL play *very* nicely with the provision HTTP makes for 
authentication means that it is more likely to be implemented within 
servers and supported directly by browsers themselves, not just within 
web-apps.

Regards.
Sam
0
Sam
10/13/2013 5:28:06 AM
On 12-10-2013 5:45, Dave Akers wrote:> Hello all,
 >    So now we have the client to server part down we need to decide the
[...]

Whatever the amount of detail the error will be, and no matter what 
mechanism is used we should always have a good way of translating the 
error to the native language of the (not technically educated) user.

So whatever message is sent back to the client it must be accompanied 
with an number indicating the error.
These error-codes should be described upfront and probably be layered 
like http error messages (e.g. 401.1, means a special case of 
Unauthorised ).
When a Client can hide the intricacies of the problem (Normal mode). The 
more technical user can request an Advanced Error.

Second reason for this is localization, I hope the enthusiastic 
programming contingent does not forget to generate pot files :)

Ivar
0
Ivar
10/13/2013 10:02:16 AM
On 2013-10-12 16:56:57 +0000, Steve Gibson said:

> 
> result={success}
>        {failure}
> 
> reason={invalidnut}
>        {stalenut}
>        {badformat}
>        {badsig}
>        {badscheme}
>        {ipnomatch}
>        {ipmatch}
> 
> detail={newuser}
>        {olduser}
> 
> link={url of logged on session}
> 

I think there should be two success responses as well.  One success 
where the client is provided with a link that *MUST* be followed to 
complete the login process.  Then optionally the website can also 
authenticate the websession in which the SQRL code was originally sent. 
 That infomration should be sent back to the client so the user knows 
what to do.  But, the options here of which to do would be up to the 
server and their level of desired protection from phising and MITM.


0
Robertson
10/13/2013 5:40:52 PM
Steve Gibson wrote:
> [for the unabridged version, see AlanD's post above]
>
>> Do we actually want to convey a detailed reason back to the
>> client, or should we just have "login failed". Telling the
>> client exactly what is wrong helps them try again and makes
>> it easier to hack.
>
> I see your point Alan. But no protocol that relies upon the
> attacker NOT knowing the reason for their failure would be
> secure anyway. As you know, the key to security is to rely
> upon one very well protected secret, rather than on anything
> that an attacker could poke at and/or guess.
>

But telling the hacker that the password or SQRL key is wrong implies that 
the username is valid. Therefore we have leaked some information. If that 
was, say, membership of a political site, I believe that it qualifies as 
Personal Data under the UK ( and European) Data Protection Acts, and 
unauthorised disclosure can be subject to criminal proceedings.

I accept that internally we might want to log the exact reason, but should 
be tell the attacker?

AlanD
0
AlanD
10/13/2013 9:59:39 PM
Reply:

Similar Artilces:

automation server to client and client to server
I have to applications that need to communicate with each other. Is it practical for both of them to be servers and clients to each other? One of the applications will work primarily as a server and will launch the other application. The newly launched application needs to be able to send occasional information to the server to update information in the application that launched it. Also, if the user attempts to close the launched application it needs to tell the launcher application to close the appl ication that it launched. Does this sound practical? This is kind of like launching wo...

Server to Server, both Servers in same Tree
Hi, where could be problem when some time connection is not established after server restart, but some time it is OK. (I waited whole day) Filters are opened for all IP from and to both servers in VPN. Both servers are BM3.7 SP2, NDS Version 10350.19 March 18, 2003 Slave server contain RW replica of the container where the server resides. (I tried also Master replica) here are also licenses for NW6 and BM3.7 Master server is in different replica which is not on slave server. Both servers are on same subnet. Packet capture shows only IP 57 communication from Master to ...

Pass values from server to client and client to server?
Hi, i have a scenario, i want to  pass some values to an image and a label dynamically from database. i want to use an anchor(a href) tag and when the mouse goes over the anchor , an image url and label text must change with the values from database. Suppose that there are more than one anchor at the page.  One more thing, anchors must get the id values of the records from database at page_Load() and the queries use these these ids again to retreive imageurl and label text values from database when ...

server or no server
i have been looking in to slipstreaming windows up dates over the net work ..i have also been thinking (bad thing to do ) installing the os over the net (image).i know you can do this over win2k server using rras server but could i do this in novell 5.1 with out bulding and paying for a server lience. our network is spread across 6 sites one server to each site a gig backbone on each site but connect by 100 mb line .not knowing novell to well but they seem not to be use the OS and Server to well .any help or info would be useful Nigel, > i have been looking in to...

How I can hold CPU in client when it post an event to a server and yield to waiting the server response?
How I can hold CPU in client when it post an event to a server and yield to waiting the server response? I mean I don't want the client can do other thing when it is waiting the response. Use Trigger instead of Post. /MicK Michael Kramer, SPS Danmark <dodo> wrote in message news:8EF228B02903CE1A00290C4185256B9C.0028FA0A85256B9C@webforums... > ...

SmtpException has occured: The SMTP server requires a secure connection or the client was not authenticated. The server response was: authentication needed
SmtpException has occured: The SMTP server requires a secure connection or the client was not authenticated. The server response was: authentication needed  What else do I have to set to make sure I can send email through my email account.  <mailSettings> <smtp from="myEmailFrom"> <network host="smtp.mydomain.com" password="mypwd" userName="myUserName" defaultCredentials="true"/> </smtp> </mailSettings> Newbie Might take a look at: http://www.systemnetmail.com/faq/4.2.aspx You might also ask your ISP or web host, there may be a unique method...

Bad sequence of commands. The server response was: This mail server requires authentication. Please check your mail client settings.
try { MailMessage message = new MailMessage(); message.From = new MailAddress("amrit@eastlandindia.com"); message.To.Add("eramrit_datasoft@yahoo.co.in"); message.Subject = "Check Mail"; message.Body = "Your loan status"; SmtpClient smtpClient = new SmtpClient("eastlandindia.com"); smtpClient.Credentials = new NetworkCredential("eastlandindia.com", "xxxxxx"); smtpClient.Send(message); } catch (Exception ex) { Response.Write(ex.Message); }   This is my code When  i Sending mail the it give the message: Bad sequence of commands. The server response was: This mai...

Client & Server Side ( Server PostBacks Reset Client Data )
Hi, Slight Problem i have bumped into, maybe someone can help me... --TestSlider.aspx--------- <%@ Page Language="C#" %> <script runat="server"> void click(object sender, EventArgs e) { Label1.Text = Label1.Text; if(btnPress.Text=="Press") btnPress.Text = "PRESS"; else btnPress.Text = "Press"; } </script> <html> <head> <script language="JavaScript"> function newSlider(sId) { sCode = '<table border=...

get error The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.5.1 Authentication Required.
 Hi,I was able to send mail with no trouble before few days.Then due to some reason, i Formatted pc &  re-installed visual studio & IIS Now when i try to send mail, i get this error.The SMTP server requires a secure connection or the client was not authenticated.In my web.config file i write<mailSettings>      <smtp from="myemail@gmail.com">        <network host="smtp.gmail.com" port="587" userName="myemail" password="xxxx" defaultCredentials="fa...

Start Client Timer from Server Event and start server Event from client event
All of you, I have a big challenge which i'm not able to resolve. I need some experts with samples on this. Situation for a webbased quiz system I have a data set with e.g. 5 questions. The process should be like 1. Load Question 1 from database, there is also a picture and a MP3 sound file 2. I connect the MP3 sound file to a webcontrol I've written to play Mp3 with a flashmovie. 3. Once this mp3 is played (the question is read for people with reading problems) an Event should be raised from the client to the server. 4. The event from 3 should start a Countdown timer (15 se...

Client-server comunication in server control
Hello, i wonder if someone could give me advice. I am building server control (scriptControl) that should show some text in tooltip after the mouseover client event is fired. But i dont want to generate this text into client instance init method, because its posible size. Instead, i want this text to be dynamicaly populateted from server. So i am asking, what is the best way to do it? In server control i can not use Services or PageMethods and i would like to avoid Callbacks (they are slow). Is there any other option? Thx in advance  Well your two options are you add it to the ...

Encryption of client/server communications from the server
Hello, Database: SQL Anywhere Version 5. The -e command-line option encrypt all packets transmitted to and from all clients, OK. What encryption algorithm is used? It's simple or strong? Encryption does marginally affect performance. It's really? What's mean "marginally", in fact? What percentage, number? I beg what anybody help me, I need understand. Thanks a lot. Renato Cramer. renato@domsis.com.br Renato Cramer wrote: > The -e command-line option encrypt all packets transmitted > to and from all clients, OK. > > What encryptio...

Client responses to a server
Updating my implementation, I noticed one thing not made explicit in the specification on the Syntax/Semantics pages, unless I missed it. When a SQRL client is sending a response back to the server, it should use the SQRL URL or the qry= value unmodified except for the following: sqrl/qrl in the scheme are changed to https/http respectively. The "|" designating the "site key string" is replaced by a "/" The qry= value will not have a scheme or "|" so nothing should be modified and the client should simply prepend the appropriate scheme...

Client response to server
Hi,Is it possible that client response to server when i click download and user/client save the file then update column in server side.and how can we do it. Any one can help me.Thanks you. we often send the content type of the downloaded files from server side to client side in the form of attachment when downloading files.You can refer to this link to get known HTTP protocols in details.http://en.wikipedia.org/wiki/HTTP ...

Web resources about - Server to Client server responses - grc.sqrl

Rational Response Squad - Wikipedia, the free encyclopedia
The reason for the suspension was due to Uri Geller claiming that Rational Response Squad had infringed his copyrights when posting a video featuring ...

Esperance bushfires: WA firefighters cop flak for response time
Firefighters have been forced to defend themselves after being criticised for response times to the deadly bushfires in Western Australia's south. ...

ISIS response addressed by Harjit Sajjan, appearing at Halifax International Security Forum
Defence Minister Harjit Sajjan today underscored the government's commitment to bringing thousands of Syrian refugees to Canada while appearing ...

Networks to Meet Monday on Response to Trump
The major cable and broadcast news networks will meet Monday to discuss a joint response to the presidential campaign of Donald Trump , which ...

Grieving husband gives ISIS the best response we’ve seen so far
... However, that’s not the right path to take, and a French man who lost his wife, the mother of his 17-month-old boy, wrote a riveting response ...

The perfect response to Joyce Carol Oates.
. @JoyceCarolOates you were great in 'The Shining' https://t.co/yeE4z7TW04 — David Burge (@iowahawkblog) November 23, 2015

Russia's response: Surface-to-air missiles in Syria
Tension mounts as Moscow moves its most advanced anti-aircraft missiles near to where fighter jet was downed in move Putin called a "stab in ...

Could France’s response to attacks boost its economy?
France’s President Francois Hollande has declared the country “at war” with Islamic State terrorists – but what are the likely economic consequences? ...

The Right Response To Terrorism
A blindfolded man in Paris stood near one of the site hit by terrorists a week ago and asked for hugs. The response was heartwarming, human, ...

A Pro-Woman Response To The Problem Of Self-Induced Abortions
Self-induced abortion is a problem worth addressing. It should not be used as a pawn by the abortion industry.

Resources last updated: 11/27/2015 9:05:10 AM